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Foreword 



This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document describes the stage 2 description (architectural solution and functionalities) for the MBMS Bearer 
Service, which includes, together with MBMS User Services defined in TS 26.346 [7], all the elements necessary to 
realise the stage 1 requirements in TS 22.146 [2] and TS 22.246 [6]. This document encompasses both GPRS and EPS. 

The present document also includes considerations on the manner in which User Services should make use of the 
MBMS Bearer Service described herein. It should be noted that the specification of MBMS User Services in 
TS 26.346 [7] takes precedence over User Service aspects described in this document. 

The present document includes information applicable to network operators, service providers and manufacturers. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions defined in TR 21.905 [1] and TS 22.146 [2] and the 
following apply: 

MBMS Service Announcement: Mechanism to allow users to be informed about the MBMS user services available. 

MBMS Bearer Service: the service provided by the PS Domain to MBMS User Services to deliver IP multicast 
datagrams to multiple receivers using minimum network and radio resources. 

MBMS User Service: the MBMS service provided to the end user by means of the MBMS Bearer Service and possibly 
other capabilities. 

MBMS Service Area: The area within which data of a specific MBMS session are sent. Each individual MBMS 
session of an MBMS Bearer Service may be sent to a different MBMS Service Area. This MBMS Service Area is the 
same or a subset of the Multicast or Broadcast Service Area as defined in TS 22.146 [2]. An MBMS Service Area 
smaller than the Multicast or Broadcast Service Area is typically used for localized services. 

MBMS over a Single Frequency Network: See TS 25.346 [10]. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations in TR 21.905 [1] and TS 22.146 [2] apply. 

EPS Evolved Packet System 

C-TEID Common TEID 

MBSFN MBMS over a Single Frequency Network 

SSM Source Specific Multicast 

TMGI Temporary Mobile Group Identity 

TPF Traffic Plane Function 



4 IVIBIVIS Architecture 

4.1 Overview 

MBMS is a point- to -multipoint service in which data is transmitted from a single source entity to multiple recipients. 
Transmitting the same data to multiple recipients allows network resources to be shared. 

The MBMS bearer service offers two modes: 
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- Broadcast Mode; 

- Multicast Mode. 

Broadcast Mode is supported for EPS and GPRS, and Multicast Mode is supported for GPRS. MBMS for EPS supports 
E-UTRAN and UTRAN. MBMS for GPRS supports UTRAN and GERAN. 

MBMS architecture enables the efficient usage of radio-network and core-network resources, with an emphasis on radio 
interface efficiency. 

MBMS is realised by the addition of a number of new capabilities to existing functional entities of the 3GPP 
architecture and by addition of a number of new functional entities. 

The existing PS Domain functional entities (GGSN, SGSN, MME, E-UTRAN, UTRAN, GERAN and UE) are 
enhanced to provide the MBMS Bearer Service. In the EPS a functional entity MBMS GW exists at the edge between 
the CN and the BM-SC. In the bearer plane, this service provides delivery of IP Multicast datagrams from the Gi and 
SGi-mb reference points to UEs with a specified Quality of Service. In the control plane, this service provides 
mechanisms for: 

managing the MBMS bearer service activation status of UEs (in the case of multicast mode); 

outsourcing authorisation decisions to the MBMS User Service (i.e. to the BM-SC) (in the case of multicast 
mode); 

providing control of session initiation/modification/termination by the MBMS User Service and managing bearer 
resources for the distribution of MBMS data (in the case or multicast and broadcast modes). 

A particular instance of the MBMS Bearer Service is identified by an IP Multicast Address and an APN Network 
Identifier. A TMGI also can be used to identify one MBMS Bearer Service inside one PLMN. 

For GPRS the boundary of the MBMS Bearer Service is the Gmb and Gi reference points as shown in Figure 1 below. 
The former provides access to the control plane functions and the latter the bearer plane. For EPS the boundary is the 
SGmb and the SGi-mb as shown in figure lb below. 

A functional entity, the Broadcast Multicast Service Centre (BM-SC) provides a set of functions for MBMS User 
Services. BM-SC functions for different MBMS User Services may be supported from the same or different physical 
network elements. 
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4.2 



Reference Architecture Model 



4.2.1 GPRS 





PDN 

(e.g. Internet ) 



Content 

Provider/ 

Multicast 

Broadcast 

Source 



Note 1 : 

Note 2: 
Note 3: 



Network entities and reference points solely used by the MBMS user service (e.g. for service 

announcement as described in section 4.4.1 .2) are not shown in this figure. 

Gp applies only when SGSN and GGSN are in different PLIVINs. 

the lu/Gn reference point above is a direct tunnel according to clause 5.6.2.2, figure 6b in TS 23.060 [15] 

with IP multicast based addressing according to RFC 4607 [21]. 



Figure la: Reference architecture for GPRS to support the MBMS bearer service with GERAN and 

UTRAN 



4.2.2 EPS 



UE 



E-UTRAN Uu 

UTRAN 











PDN 




IVIIVIE 


Gateway 


IVIS ^^^ 


SGmb 








- 


Sm 


-SGi 


^^^^^ 




BIVI-SC - 


J . 


IVIBIVIS 


1 

1 


Ml^,-""""^ 


G\ 


N 


SGi-mb 







Content Provider 




Figure lb: Reference architecture for Evolved Packet System with E-UTRAN and UTRAN (MBMS 

Broadcast Mode only) 

NOTE 1: In addition to MBMS Bearers (over SGmb/SGi-mb), the BM-SC may use EPS Bearers (over SGi) to 
realize an MBMS User Service as specified in TS 26.346 [7]. 

NOTE 2: The MCE (Muhi-cell/Muhicast Coordination Entity) is not shown in the figure. 

NOTE 3: MBMS service over Gn-SGSN is supported when the MBMS-GW is co-located with the PDN GW and 
this PDN GW has the necessary GGSN functions to control the MBMS Bearer Service over Gn. 
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4.3 MBMS Specific Reference points 

4.3.1 Gmb 

Signalling between GGSN and BM-SC is exchanged at Gmb reference point. This represents the network side boundary 
of the MBMS Bearer Service from a control plane perspective. This includes user specific Gmb signalling and MBMS 
bearer service specific signalling. 

MBMS bearer service specific Gmb signalling: 

- The GGSN estabhshes the MBMS bearer context and registers at BM-SC. 

- The GGSN or the BM-SC releases the MBMS bearer context and de-registers the GGSN from the BM-SC. 

The BM-SC indicates session start, update and stop to the GGSN including session attributes like QoS and 
MBMS service area. 

User specific Gmb signalling: 

The BM-SC authorises the user specific MBMS multicast service activation (join) at the GGSN. 

The GGSN reports to the BM-SC the successful user specific MBMS multicast activation (join) to allow the 
BM-SC to synchronise the BM-SC MBMS UE context with the MBMS UE contexts in the SGSN and GGSN. 

The GGSN reports to the BM-SC when a user specific MBMS multicast service is released or deactivated (e.g. 
at implicit detach). The GGSN makes this report in order to synchronise the BM-SC MBMS UE context with the 
MBMS UE contexts in the SGSN and GGSN. 

The BM-SC initiates the deactivation of a user specific MBMS bearer service when the MBMS user service is 
terminated. 

BM-SC functions for different MBMS bearer services may be provided by different physical network elements. Further, 
MBMS bearer service specific and user specific signalling for the same MBMS bearer service may also be provided by 
different physical network elements. To allow this distribution of BM-SC functions, the Gmb protocol must support the 
use of proxies to correctly route the different signalling interactions in a manner which is transparent to the GGSN. 

4.3.1a SGmb 

The SGmb reference point has similar functions with the Gmb interface in control plane except for the Multicast Mode 
related functions. Specifically, 

MBMS bearer service specific SGmb signalling: 

The BM-SC indicates session start, update and stop to the MBMS-GW including session attributes like QoS and 
MBMS service area, and some of attributes may be different from them in Gmb. 

4.3.2 IVIz 

Mz is the roaming variant of the Gmb reference point with the same functionality as described under Gmb, i.e. with 
MBMS bearer and User specific signalling. 

MBMS bearer and User specific Mz signalling is used between a BM-SC in the visited PLMN and a BM-SC in the 
home PLMN when MBMS services from the home PLMN are offered by the visited PLMN. 

User specific signalling is used between a BM-SC in the visited PLMN and a BM-SC in the home PLMN when the 
visited PLMN offers MBMS user services to roaming users. This user specific Mz signalling provides home PLMN 
authorisation for MBMS user services that are provided by the visited PLMN. This mechanism supports only MBMS 
user service classes that are offered by the visited and by the home PLMN. 

Mz may use proxying capabilities as described for Gmb, e.g. to proxy signalling between BM-SCs. An APN may be 
included in the signalling between BM-SCs, which is used to select an appropriate GGSN to access the MBMS service 
aiming for an optimized routing, resource saving, or operator policy. 
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NOTE: For EPS, the Mz reference point is not supported in this release. 

4.3.3 Reference Points for Evolved Packet System 

NOTE: The below listed reference points are applicable for the E-UTRAN and UTRAN MBMS Broadcast Mode 
(with or without counting) only. 



Ml: 

M3: 
Sm: 
Sn: 



It is the reference point between MBMS GW and E-UTRAN/UTRAN for MBMS data delivery. IP 
Multicast is used on this interface to forward data. 

It is the reference point for the control plane between MME and E-UTRAN. 

It is the reference point for the control plane between MME and MBMS GW. 

It is the reference point between MBMS GW and SGSN (S4 based) for the control plane and for 
MBMS data delivery. Point-to-point mode is used on this interface to forward data.. 



It is the reference point between BM-SC and MBMS GW function for MBMS data dehvery. 
It is the reference point for the control plane between BM-SC and MBMS GW. 



SGi-mb: 
SGmb: 

Protocol assumption: 

The Sm reference point is based on GTPv2-C. 

The Sn reference point is based on GTPv2-C and GTPvl-U. 

The Ml reference point is based on GTPvl-U. 



4.4 



MBMS Service Provision 



4.4.1 



IVIULTICAST IVIODE 



Reception of an MBMS MULTICAST service is enabled by certain procedures that are illustrated in the Figure below. 
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Subscription 



Service announcement 



Joining 



Session start 



IVIBIVIS notification 



Data transfer 



Session Stop 



Leaving 




Figure 2: Phases of MBMS Multicast service provision 

The phases subscription, joining and leaving are performed individually per user. The other phases are performed for a 
service, i.e. for all users interested in the related service. The sequence of phases may repeat, e.g. depending on the need 
to transfer data. Also subscription, joining, leaving, service announcement as well as MBMS notification may run in 
parallel to other phases. 

This is illustrated with the following example of timeline: 
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Figure 3: Timeline example 



4.4.1.1 



Subscription 



Establishes the relationship between the user and the service provider, which allows the user to receive the related 
MBMS multicast service. 

Service Subscription is the agreement of a user to receive service(s) offered by the operator. Subscription information is 
recorded in the BM-SC. Subscription information and other BM-SC functionality may be on separate entities, which is 
enabled by proxy capability of the Gmb interface. 

NOTE: procedures for the subscription phase are out of scope of this specification. 



4.4.1.2 



Service announcement 



MBMS user service announcement/discovery mechanisms shall allow users to request or be informed about the range 
of MBMS user services available. This includes operator specific MBMS user services as well as services from content 
providers outside of the PLMN. Service announcement is used to distribute to users information about the service, 
parameters required for service activation (e.g. IP multicast address(es)) and possibly other service related parameters 
(e.g. service start time). 

Operators/service providers may consider several service discovery mechanisms. This could include standard 
mechanisms such as SMS, or depending on the capability of the terminal, applications that encourage user interrogation. 
The method chosen to inform users about MBMS user services may have to account for the user' s location, (e.g. current 
cell, in the HPLMN or VPLMN). Users who have not already subscribed to a MBMS user service should also be able to 
discover MBMS user services. 

The following could be considered useful for MBMS user service announcement mechanisms (not exhaustive): 

SMS Cell Broadcast to advertise MBMS Multicast and Broadcast user services; 

- MBMS Broadcast mode to advertise MBMS Multicast and Broadcast user Services; 
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- MBMS Multicast mode to advertise MBMS Multicast user Services; 

- PUSH mechanism (WAP, SMS-PP, MMS); 

- URL (HTTP, FTP). 

The details of the MBMS service announcement mechanisms are out of scope of this specification, but MBMS shall 
allow the utilisation of solutions using IETF protocols. 

Service announcement is further defined within MBMS User Service specifications TS 26.346 [7]. 

4.4.1.3 Joining 

Joining (i.e. MBMS multicast activation by the user) is the process by which a subscriber joins (becomes a member of) 
a multicast group, i.e. the user indicates to the network that he/she wants to receive Multicast mode data of a specific 
MBMS bearer service. An MBMS user service may also be carried by more than one MBMS bearer service. In that 
case the MBMS user service part in the UE initiates the relevant MBMS bearer services to receive the service (see 
clause 8.2). 

4.4.1.4 Session Start 

Session Start is the point at which the BM-SC is ready to send data. This can be identified with the start of a "Multicast 
session" as defined in TS 22. 146 [2]. Session Start occurs independently of activation of the service by the user - i.e. a 
given user may activate the service before or after Session Start. Session Start is the trigger for bearer resource 
establishment for MBMS data transfer. If an MBMS user service is carried by more than one MBMS bearer service, a 
Session Start message is sent for each MBMS bearer service. In that case the UE may need to initiate the reception of 
multiple relevant MBMS bearer services to receive the MBMS user service. 

4.4.1.5 MBMS notification 

Informs the UEs about forthcoming (and potentially about ongoing) MBMS multicast data transfer. 

4.4.1.6 Data transfer 

It is the phase when MBMS data are transferred to the UEs. 

4.4.1.7 Session Stop 

It is the point at which the BM-SC determines that there will be no more data to send for some period of time - this 
period being long enough to justify removal of bearer resources associated with the session. At Session Stop, the bearer 
resources are released. 

4.4.1.8 Leaving 

Leaving (i.e. MBMS multicast deactivation by the user) is the process by which a subscriber leaves (stops being a 
member of) a multicast group, i.e. the user no longer wants to receive Multicast mode data of a specific MBMS bearer 
service. 

4.4.2 Multicast Mode timeline 

4.4.2.1 Period between Service Announcement and Session Start 

The service announcement may contain a schedule of Session Start times and may be sent some time before the service 
is due to start. So, this time period could be hours, days or even weeks. 

4.4.2.2 Period between Service Announcement and Service Subscription 

Service Subscription can be done anytime before or after Service announcement. 
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4.4.2.3 Period between Service Announcement and Joining 

The Joining time is chosen by the user and/or UE possibly in response to a Service Announcement. Users will typically 
join at the time of their choosing so that the period between announcement and joining may be very long or very short. 
In order to avoid overload situations being caused by many users attempting to join in a short period of time, the UE 
shall be able to use parameters sent by the BM-SC in the service announcement to randomise the joining time. 

4.4.2.4 Period between Joining and Session Start 

Some MBMS bearer services may be 'always on'. In this case, Joining can take place immediately after Service 
Announcement and possibly many hours before, or after. Session Start. 

In other cases, if a Session Start time is known. Joining may take place immediately before Session Start or after 
Session Start. For these services, the announcement may contain some indication of a time period which users and UEs 
should use to choose a time to Join the MBMS bearer service. 

4.4.2.5 Period between Session Start and First Data Arrival 

Session Start indicates that the transmission is about to start. The time delay between a Session Start indication and 
actual data should be long enough for the network actions required at Session Start to take place e.g. provision of 
service information to the UTRAN, establishment of the bearer plane. 

Session Start may be triggered by an explicit notification from the BM-SC. In the case of bearer plane resources which 
are set-up after the start of session data transmission, the network is not required to buffer the session data and loss of 
data can be assumed. 

4.4.2.6 Period between Session Start and Session Stop 

When the BM-SC knows that there is no more data to be sent for a "long idle period", it should indicate Session Stop to 
the network, causing the release of bearer resources. However, if this idle period with no data is short, this may not be 
appropriate as it brings more signalling and processing. 

The duration of this "long idle period" is implementation dependent. The order of magnitude should be defined to take 
into account network constraints (including UTRAN, GERAN, and CN). 

If the BM-SC wants to use session repetition identification on the MBMS bearer service level, the BM-SC must stop the 
MBMS session before starting the next MBMS user service session for that TMGI. 

4.4.2.7 Session Update 

Session Update is used to update specific parameters of an ongoing MBMS Multicast session. The SGSN can use the 
procedure to update the list of RAs where MBMS multicast users are located for an ongoing MBMS Multicast service 
session. 

4.4.3 BROADCAST MODE 

An example for the phases of MBMS broadcast service provision is described in the figure below: 
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Service announcement 



Session Start 



IVIBIVIS notification 



Data transfer 



Session Stop 




Figure 4: Phases of MBMS broadcast service provision 

The sequence of phases may repeat, e.g. depending on the need to transfer data. It is also possible that the service 
announcement and MBMS notification phase may run in parallel with other phases, in order to inform UEs which have 
not yet received the related service. 
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Broadcast of Data, received by any UE 
which is present 



Figure 5: Broadcast service timeline 

4.4.3.1 Service announcement 

Informs UEs about forthcoming MBMS user services. Also see section on Multicast mode (4.4.1.2). 



4.4.3.1a 



UE local service activation 



The MBMS user service part in the UE initiates reception of the MBMS bearer service to receive an MBMS user 
service. In case one MBMS user service is carried by more than one MBMS bearer service, the UE may need to initiate 
the reception of multiple relevant MBMS bearer services to receive the MBMS user service (see clause 8.12). 



4.4.3.2 



Session Start 



Session Start is the point at which the BM-SC is ready to send data. This can be identified with the start of a "Broadcast 
session" as defined in TS 22. 146 [2]. Session Start is the trigger for bearer resource establishment for MBMS data 
transfer. If an MBMS user service is carried by more than one MBMS bearer service, a Session Start message is sent for 
each MBMS bearer service. In that case the UE may need to initiate the reception of multiple relevant MBMS bearer 
services to receive the MBMS user service. 

4.4.3.3 MBMS notification 

Informs the UEs about forthcoming (and potentially about ongoing) MBMS broadcast data transfer. 

4.4.3.4 Data transfer 

It is the phase when MBMS data are transferred to the UEs. 
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4.4.3.5 Session Stop 

It is the point at which the MBMS user service determines that there will be no more data to send for some period of 
time - this period being long enough to justify removal of bearer resources associated with the service. At Session Stop, 
the bearer resources are released. 

4.4.3.6 Session Update 

Session Update is used to update specific parameters of an ongoing MBMS Broadcast session. Parameters which can be 
updated are MBMS Service Area, and/or the List of SGSNs/MMEs (only from BM-SC to GGSN or MBMS GW). A 
Session Update received in one node, results in a Session Update being sent to downstream nodes, to inform of the 
changed MBMS Service Area. When a Session Update is received in the GGSN or MBMS GW including the List of 
SGSN/MME parameter, it results in a Session Start being sent to new downstream nodes, and in a Session Stop being 
sent to downstream nodes that have been removed from the list. 

4.4.4 Broadcast Mode timeline 

4.4.4.1 Period between Service Announcement and Session Start 

Same as for Multicast mode. 

4.4.4.2 Period between Session Start and First Data Arrival 

Same as for Multicast mode. 

4.4.4.3 Period between Session Start and Session Stop 

Same as for Multicast mode. 



Functional Entities To Support IVIBIVIS 



5.0 General 

To provide MBMS bearer services existing functional entities, GGSN, MME, SGSN, eNodeB/RNC/BSC, perform 
several MBMS related functions and procedures, some of which are specific to MBMS. An MBMS specific functional 
entity - Broadcast Multicast Service Centre (BM-SC) supports various MBMS user service specific services such as 
provisioning and delivery. In the EPS a functional entity MBMS GW exists at the edge between the CN and the 
BM-SC. 

5.1 Broadcast-Multicast Service Centre (BM-SC) 
5.1.0 General 

The BM-SC provides functions for MBMS user service provisioning and delivery. It may serve as an entry point for 
content provider MBMS transmissions, used to authorise and initiate MBMS Bearer Services within the PLMN and can 
be used to schedule and deliver MBMS transmissions. 

The BM-SC is a functional entity, which must exist for each MBMS User Service. 

The BM-SC consists of the following sub-functions: 

Membership function; 

Session and Transmission function; 

- Proxy and Transport function; 
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Service Announcement function; 
Security function. 

- Content synchronization for MBMS in UTRAN. 

Content synchronization for MBMS in E-UTRAN for broadcast mode. 

- Header compression for MBSFN MBMS data in UTRAN. 

NOTE: Header compression of MBMS data is not supported in E-UTRAN for this Release. 
This section describes BM-SC functions, which are defined for the standardised MBMS User Services. 
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Figure 5a: BM-SC functional structure 



5.1.1 Membership Function 



The BM-SC Membership function provides authorization for UEs requesting to activate an MBMS service. 

The Membership function may have subscription data of MBMS service users. 

The Membership Function may generate charging records for MBMS service users. 

The Membership Function is an MBMS bearer service level function, but it may also provide user service level 
functions e.g. membership management etc. In this case it does also have a Gi/SGi interface. 

5.1 .2 Session and Transmission Function 

The BM-SC Session and Transmission Function shall be able to schedule MBMS session transmissions. 

The BM-SC Session and Transmission Function should be able to schedule MBMS session retransmissions, and label 
each MBMS session with an MBMS Session Identifier to allow the UE to distinguish the MBMS session 
retransmissions. The BM-SC Session and Transmission Function allocates TMGIs. 

Each transmission and subsequent retransmission(s) of a specific MBMS session are identifiable by a common MBMS 
Session Identifier (2-3 Octets) passed at the application layer in the content, and also passed in a shortened form (i.e. the 
least significant octet) in the MBMS Session Start Request message to the eNodeBs/RNCs/BSCs. The full MBMS 
Session Identifier should be used by the UE to identify an MBMS session when completing point-to-point repair, while 
the shortened MBMS Session Identifier is included by the RANs in the notification messages for MBMS 

The BM-SC Session and Transmission Function shall be able to provide the MBMS GW or GGSN with transport 
associated parameters such as quality-of-service and MBMS service area. 
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The BM-SC Session and Transmission Function shall be able to initiate and terminate MBMS bearer resources prior to 
and following transmission of MBMS data. 

The BM-SC Session and Transmission Function should be able to send MBMS data. It could also apply favourable 
error resilient schemes e.g. specialized MBMS codecs or Forward Error Correction schemes. 

When IP multicast is used for distribution of payload from GGSN to RNC or from MBMS GW to eNodeB and RNC, 
the BM-SC Session and Transmission Function shall include synchronization information for the MBMS payload. If the 
header compression is used over the radio, the compression is done in the BM-SC. The details of synchronization and 
header compression for the MBMS payload are specified in TS 25.346 [10] and TS 25.446 [18]. 

The BM-SC Session and Transmission Function should be able to authenticate and authorize external sources and 
accept content from them. 

The Session and Transmission Function is user service level function and it triggers bearer level functions when MBMS 
sessions are scheduled. 

5.1 .3 Proxy and Transport Function 

The BM-SC Proxy and Transport Function is a Proxy Agent for signalling over SGmb and Gmb reference points 
between MBMS GWs/GGSNs and other BM-SC sub-functions, e.g. the BM-SC Membership Function and the BM-SC 
Session and Transmission Function. Further, the BM-SC Proxy and Transport Function shall also be able to handle 
when BM-SC functions for different MBMS services are provided by multiple physical network elements. Routing of 
the different signalling interactions shall be transparent to the MBMS GW and the GGSN. 

The BM-SC Proxy and Transport function shall be able to generate charging records for content provider charging of 
transmitted data. Content provider name is provided to BM-SC Proxy and Transport function over SGmb/Gmb at 
session start. 

The BM-SC Proxy and Transport function may act as an intermediate device for the MBMS data sent from the BM-SC 
Session and Transmission function to the MBMS GW or GGSN. 

The Proxy and Transport Function may be divided further into a Proxy function managing the control plane 
(SGmb/Gmb) and a Transport function managing the multicast payload. 

The Proxy and Transport Function is an MBMS bearer service function. 

5.1 .4 Service Announcement Function 

The BM-SC Service Announcement function shall be able to provide service announcements for multicast and 
broadcast MBMS user services. 

The BM-SC Service Announcement function shall be able to provide the UE with media descriptions specifying the 
media to be delivered as part of an MBMS user service (e.g. type of video and audio encodings). 

The BM-SC Service Announcement function shall be able to provide the UE with MBMS session descriptions 
specifying the MBMS sessions to be delivered as part of an MBMS user service (e.g. multicast service identification, 
addressing, time of transmission, etc.). 

The BM-SC Service Announcement function shall be able to deliver media and session descriptions by means of 
service announcements using IETF specified protocols over MBMS multicast and broadcast bearer services. 

The Service Announcement Function is a user service level function. 

The following mechanisms should be supported for service announcement. Service announcements may be triggered by 
the BM-SC but are not necessarily sent by the BM-SC: 

MBMS bearer capabilities to advertise MBMS user Services; 

- PUSH mechanism (WAP push); 

- URL (WAP, HTTP); 

- SMS (point-to-point); 



£75/ 



3GPP TS 23.246 version 1 0.0.0 Release 1 22 ETSI TS 1 23 246 V1 0.0.0 (201 1 -03) 

- SMS-CB cell broadcast. 

Other mechanisms could be considered in future releases. 

5.1 .4a MBMS Security Function 

MBMS user services may use the Security functions for integrity and/or confidentiality protection of MBMS data. The 
MBMS Security function is used for distributing MBMS keys (Key Distribution Function) to authorized UEs. Detailed 
description of the security functions is provided in (TS 33.246 [5]). 

5.1 .5 MBMS Content Transfer for the same MBMS User Service for 
GPRS and EPS 

5.1.5.1 General 

For GPRS, although these procedures mention GERAN and UTRAN extensively, only the BM-SC (which renders the 
content differently) and the SGSN have to implement functionality to deliver this. The GGSN, RNC and BSC shall all 
be transparent to this functionality. 

For EPS, although these procedures mention UTRAN and E-UTRAN extensively, only the BM-SC and the MBMS-GW 
have to implement functionality to deliver this. The MME, S4-SGSN, RNC and eNodeB remain transparent to this 
functionality. 

5.1 .5.2 Separate MBMS Bearer Services for the same MBMS User Service 

The same MBMS user service may transfer its data on separate MBMS bearer services for different access 
technologies, typically with different QoS, e.g. for GRPS using separate MBMS bearer services for GERAN and 
UTRAN or for EPS using separate MBMS bearer services for UTRAN and E-UTRAN. For this purpose two IP 
multicast addresses (multicast mode only) and/or two TMGIs should be allocated for the same MBMS user service. One 
IP multicast address (multicast mode only) and/or one TMGI is for, e.g. GERAN, and another IP multicast address 
(multicast mode) and/or another TMGI is for, e.g. UTRAN. The detailed impacts on the network nodes are listed below: 

a) The service announcement instructs the UE to join two multicast MBMS bearer services (e.g. for GRPS one is 
for GERAN and the other is for UTRAN), i.e. for multicast mode, two IP multicast addresses that are allocated 
in the BM-SC are sent to UE within one service announcement message. 

NOTE 1 : One MBMS User Service may use several MBMS Bearer Services. 

b) A UE that might move between areas covered by different access technologies activates both MBMS bearer 

services. 

c) The UE monitors the paging/notification channels for both TMGIs and receives MBMS data when transferred by 
the MBMS bearer services. 

d) When the BM-SC needs to deliver the content, the BM-SC produces two sets of MBMS data from the same 
content and sends independent Session Start messages for both of the MBMS bearer services. The "different" 
content streams for the same MBMS user service are sent on the separate MBMS bearer services. For GPRS, a 
2G/3G indicator in the Session Start message (which the GGSN passes transparently to the SGSN) indicates 
whether the content should be delivered in GERAN-only or UTRAN -only (or both) coverage areas. 

e) For GPRS, the SGSN uses the 2G/3G indicator to decide whether a MBMS Session Start Request message 
should be sent to the BSCs and/or the RNCs. 

NOTE 2: See clause 7.3 for potential issues. 

5.1 .5.3 Same MBMS Bearer Service for the same MBMS User Service 

The same MBMS user service may also transfer its data on the same MBMS bearer service for multiple access 
technologies, i.e. for GRPS using a same MBMS bearer service for GERAN and UTRAN or for EPS using a same 
MBMS bearer service for UTRAN and E-UTRAN. For this purpose one IP multicast address (multicast mode only) 
and/or one TMGI should be allocated for the same MBMS user service. In such application, the "different" content for 
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the same MBMS user service are sent in separate MBMS Sessions sequentially. For GRPS, the 2G/3G indicator in the 
Session Start message indicates whether the MBMS session should be delivered in GERAN-only or UTRAN-only (or 
both) coverage areas and the SGSN uses the 2G/3G indicator to decide whether a MBMS Session Start Request 
message should be sent to the BSCs and/or the RNCs. 

NOTE: The same MBMS bearer service for both UTRAN and E-UTRAN may be used if the BM-SC does not 
execute header compression for the MBMS service. 

5.1 .6 Location Dependent Content Transfer for the same MBMS User 
Service (Broadcast Mode only) 

Some MBMS user services may broadcast different content in different areas of the network. In such case the UE is not 
aware of the relation between location and content, i.e. the UE just activates the reception of the service and receives the 
content that is relevant for its location. 

The BM-SC controls which content is broadcasted in which area by establishing a separate MBMS bearer service for 
each content data flow. All MBMS bearer services of the same MBMS user service share the same TMGI but bear a 
different Flow Identifier. The BM-SC allocates the Flow Identifier during the MBMS Session Start procedure and 
initiates a separate session for each content data flow. For IP Multicast support in EPS, the MBMS GW allocates an IP 
Multicast Address based on the TMGI and Flow Identifier (broadcast mode only). Since in any specific location only 
one version of the content shall be available at any point in time, the MBMS Service Areas of each session of a same 
user service shall not overlap; this shall be ensured by proper configuration of the service in the BM-SC. The RNC and 
the eNodeB ultimately enforces this constraint by rejecting any session start request with the same TMGI as an already 
active session if there is any overlap in the respective service areas. As indicated above, the UE is unaware of the Flow 
Identifier and of the existence of multiple sessions for the same MBMS user service. 

5.2 User Equipment 

The UE shall support functions for the activation/deactivation of the MBMS bearer service. 

Once a particular MBMS bearer service is activated, no further explicit user request is required to receive MBMS data 
although the user may be notified that data transfer is about to start. 

The UE shall support security functions as appropriate for MBMS. 

The UE should, depending on terminal capabilities, be able to receive MBMS user service announcements, paging 
information (non MBMS specific) and support simultaneous services (for example the user can originate or receive a 
call or send and receive messages whilst receiving MBMS video content). Reception of this paging or announcements 
may however, create losses in the MBMS data reception. The MBMS user service should be able to cope with such 
losses. 

A UE in Multicast Mode shall be able to synchronise with the SGSN, which of its MBMS UE contexts are still active. 

Depending upon terminal capability, UEs may be able to store MBMS data. This may involve DRM but this is out of 
scope of this specification. 

The MBMS Session Identifier contained in the notification to the UE shall enable the UE to decide whether it needs to 
ignore the forthcoming transmission of MBMS session (e.g. because the UE has already received this MBMS session). 

5.3 UTRAN/GERAN 

UTRAN/GERAN are responsible for efficiently delivering MBMS data to the designated MBMS service area. 

Efficient delivery of MBMS data in multicast mode may require mechanisms in the UTRAN/GERAN, e.g. the number 
of users within a cell prior to and during MBMS transmission could be used to choose an appropriate radio bearer. 

MBMS transmissions may be initiated and terminated intermittently. The UTRAN/GERAN shall support the initiation 
and termination of MBMS transmissions by the core-network. Further, the UTRAN/GERAN shall be able to receive 
MBMS data from the core-network over lu bearers shared by many UEs. 
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.UTRAN (and GERAN in lu mode) may also support reception of MBMS data from the core-network over IP 
multicast. When UTRAN (or GERAN lu mode) supports IP multicast reception, the UTRAN (GERAN lu mode) should 
support TEID coordination, i.e. avoid using the same value ranges for its own unicast TEIDs as are used by the GGSN 
and MBMS GW for the Common TEID-Us (C-TEIDs). If clashes anyhow occur, the RNC (lu mode BSC) shall reject 
IP multicast reception and fallback to normal shared lu bearers for reception of MBMS data. 

The UTRAN/GERAN shall support both intra-RNC/BSC and inter-RNC/BSC mobility of MBMS receivers. Mobility is 
expected to cause limited data loss. Therefore, MBMS user services should be able to cope with potential data loss 
caused by UE mobility. 

The UTRAN/GERAN shall be able to transmit MBMS user service announcements, paging information (non MBMS 
specific) and support other services in parallel with MBMS (for example depending on terminal capabilities the user 
could originate or receive a call or send and receive messages whilst receiving MBMS video content). 

5.4 SGSN 

The SGSN's role within the MBMS architecture is to perform MBMS bearer service control functions for each 
individual UE and to provide MBMS transmissions to UTRAN/GERAN. When IP multicast is used for MBMS 
transmissions the SGSN is bypassed in the 3G case (and GERAN lu mode case), i.e. MBMS data sent directly from 
GGSN to RNC (or lu mode BSC) or from MBMS GW to RNC in EPS. 

The SGSN shall provide support for intra-SGSN and inter-SGSN mobility procedures. Specifically this requires the 
SGSN to store a user-specific MBMS UE context for each activated multicast MBMS bearer service and to pass these 
contexts to the new SGSN during inter-SGSN mobility procedures. 

The SGSN shall be able to indicate its MBMS support to the UE as well as it shall be able to synchronise with the UE, 
which of the UE's MBMS UE contexts are still active. 

The SGSN shall be able to generate charging data per multicast MBMS bearer service for each user. The SGSN does 
not perform on-line charging for either the MBMS bearer service or the MBMS user service (this is handled in the BM- 
SC). 

The SGSN shall be able to establish lu and Gn bearers shared by many users upon receiving a session start from the 
GGSN. Likewise, the SGSN shall be able to tear down these bearers upon instruction from the GGSN. 

When MBMS in EPS for UTRAN access is supported, the SGSN shall support the necessary control plane functions 
provided via Sn interface to/from MBMS GW. 

5.5 GGSN 

The GGSN role within the MBMS architecture is to serve as an entry point for IP multicast traffic as MBMS data. Upon 
notification from the BM-SC the GGSN shall be able to request the establishment of a bearer plane for a broadcast or 
multicast MBMS transmission. Further, upon BM-SC notification the GGSN shall be able to tear down the established 
bearer plane. Bearer plane establishment for multicast services is carried out towards those SGSNs and /or RNCs that 
have requested to receive transmissions for the specific multicast MBMS bearer service. For an optimized bearer plane, 
IP multicast transport may be used within the core network. The bearer plane is then established between the GGSN and 
the RNCs. 

When IP multicast is used for distribution payload from GGSN to RNC, and one or more RNC rejects IP multicast 
distribution, the GGSN should in parallel with the IP multicast distribution provide legacy MBMS payload distribution 
(i.e. using point-to-point GTP -tunnels) via the SGSNs to these RNCs. In that case, the GGSN shall remove the 
synchronisation protocol elements included by the BM-SC (i.e. synchronization information and the compressed 
header) before forwarding the payload on the legacy path (see TS 25.446 [18]). 

The GGSN shall be able to receive MBMS specific IP multicast traffic and to route this data to the proper IP multicast 
distribution address and/or GTP tunnels set-up as part of the MBMS bearer service. 

The GGSN may also provide features that support the MBMS bearer service that are not exclusive to MBMS. Examples 
are: 

Message Screening (not needed if the MBMS sources are internal in the PLMN); 
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- Charging Data Collection; 

Flow Based Charging (see section 10). 

5.6 MBMS Data Sources and Content Provider 

The reference point from the content provider to the BM-SC is not standardised by 3GPP in this release of the 
specification. 

5.7 Other Functional Element 

5.7.1 Void 

5.7.2 CBC 

The Cell Broadcast Centre (CBC) may be used to announce MBMS user services to the users. 

5.7.3 Void 

5.8 Void 



5.9 Functional Elements for the Evolved Packet System 
5.9.1 IVIBIVISGW 

One or more MBMS GW function entities may be used in a PLMN. 

Note that MBMS GW may be stand alone or co-located with other network elements such as BM-SC or combined 
S-GW/PDN GW. 

MBMS GW functions include: 

It provides an interface for entities using MBMS bearers through the SGi-mb (user plane) reference point; 

It provides an interface for entities using MBMS bearers through the SGmb (control plane) reference point; 

IP multicast distribution of MBMS user plane data to eNodeBs (Ml reference point); 

IP multicast distribution of MBMS user plane data to RNCs (Ml reference point); 

NOTE 1 : In case of mobility in or out from an MBMS service area, the service continuity is handled by the Service 
Layer (in UE and network). 

It allocates an IP Multicast address to which the eNodeB/RNC should join to receive the MBMS data. This IP 
Multicast address together with the IP address of the multicast source (SSM) and a C-TEID is provided to the 
eNodeB via MME and to the RNC via SGSN; 

NOTE 2: The IP Multicast Address and the C-TEID are allocated based on MBMS bearer service uniquely 
identified by the TMGI and Flow Identifier (Broadcast mode only). 

NOTE 3: Care should be taken to avoid clashes among C-TEIDs generated in MBMS-GWs. and 
UTRAN/E-UTRAN. 
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MBMS GW may support fall back to point to point mode where applicable for UTRAN access; 
- MBMS GW can communicate with multiple control plane entities (i.e. MME, SGSN and BM-SCs). 

5.9.2 MBMS Control plane function 

The MBMS control plane function is supported by MME for E-UTRAN access and by SGSN for UTRAN access. For 
SGSN functions, see clause 5.4. 

One or more MBMS control plane functional entities are used in a PLMN. 

MME supports the following functions in order to enable MBMS support for E-UTRAN: 

Session control of MBMS bearers to the E-UTRAN access (including reliable delivery of Session Start/Session 
Stop to E-UTRAN); 

Transmit Session control messages towards multiple E-UTRAN nodes; 

It is FFS whether there is a need to filter the distribution of Session Control message to E-UTRAN nodes based 
on MBMS service area; 

It provides an Sm interface to the MBMS GW function: it receives MBMS service control messages and the IP 
Multicast address for MBMS data reception from MBMS GW function over the Sm interface. 

NOTE: When a UE leaves or enters MBMS bearer coverage, the service continuity is handled by the Service 
Layer (in UE and network). 

5.9.3 E-UTRAN 

E-UTRAN is responsible for efficiently delivering MBMS data to the designated MBMS service area. 
The E-UTRAN for MBMS in EPS shall have capability of receiving IP multicast distribution. 



6 MBMS Attributes and Parameters 

6.1 MBMS UE Context 

The MBMS UE Context is used in Multicast Mode and contains UE-specific information related to a particular MBMS 
bearer service that the UE has joined. An MBMS UE Context is created in the UE, SGSN,GGSN and BM-SC 
Membership function when the UE joins an MBMS bearer service. In the SGSN, an MBMS UE Context is also created 
as a result of an inter-SGSN routing area update after the transfer of the MBMS UE Context from the old SGSN. 

In lu mode, all MBMS UE Contexts of a UE are provided via MBMS UE Linking mechanism to the BSC/SRNC at 
least when the first PS RAB is established for the UE, or when the UE performs MBMS Multicast Service Activation. 
MBMS UE Contexts are provided to the lu mode BSC/SRNC regardless whether MBMS Sessions are ongoing or not 
(i.e. before, between and after Sessions). In addition, all MBMS UE Contexts of a UE are provided via MBMS UE 
Linking mechanism when a UE, which has an MBMS UE Context active, moves to PMM-Connected state via the 
MBMS Service Request procedure for the purpose of MBMS. 

In the UE and SGSN, the MBMS UE Context is stored as part of the MM Context for the UE. The MBMS UE Context 
is stored in the GGSN. There is one MBMS UE Context per MBMS bearer service that the UE has joined. 

In the lu mode BSC/RNC, the MBMS UE Contexts are stored as part of the UE Context of the BSC/RNC. 

The content of the MBMS UE Context is described in Table 1. 
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Table 1 : MBMS UE Context 



Parameter 


Description 


UE 


SGSN 


GGSN 


RNC 


BSC 


BM-SC 


IP multicast address 


IP multicast address identifying an 
MBMS bearer that the UE has joined. 


X 


X 


X 


X 


lu-X 
Gb - none 


X 


APN 


Access Point Name on which this IP 
multicast address is defined. 


X 


X 


X 


X 


lu-X 
Gb - none 


X 


GGSN Address in 
Use 


The IP address of the GGSN currently 
used 




X 










SGSN address 


The IP address of SGSN 






X 








TMGI 


Temporary Mobile Group Identity 
allocated to the MBMS bearer. 


X 


X 




X 


lu-X 
Gb - none 




RAI 


The Routing Area Identity 




(5) 










Linked NSAPI 


NSAPI of the PDP context used by 
the UE to carry IGMP/MLD signalling. 


X 


X 










IMSI 


IMSI identifying the user. 


(1) 


(1) 


X 


(2) 


lu - (2) 
Gb - (3) 


X 


Tl 


Transaction Identifier 


X 


X 










TEID for Control 
Plane 


The Tunnel Endpoint Identifier for the 
control plane between SGSN and 
GGSN. 




X 


X 








MBMS_NSAPI 


Network layer Service Access Point 
Identifier which identifies an MBMS 
UE Context. 


X 


X 


X 


X 






Additional MBMS 
Trace Info 


Identifies additional information 
required to perform trace. 




(4) 


(4) 






(4) 


Trace Reference 


Identifies a record or a collection of 
records for a particular trace. 




(4) 


(4) 


(4) 


(4) 




Trace Type 


Indicates the type of trace. 




(4) 


(4) 


(4) 


(4) 




Trigger Id 


Identifies the entity that initiated the 
trace. 




(4) 


(4) 


(4) 


(4) 




OMG Identity 


Identifies the OMC that shall receive 
the trace record(s). 




(4) 


(4) 


(4) 


(4) 




(1 ) In the UE and SGSN, the IMSI is available within the MM Context which contains the MBMS UE Context. 

(2) The IMSI is available within the UE Context which contains the MBMS UE Context. 

(3) IMSI availability does not depend on MBMS. 

(4) Trace parameters are only stored if trace is activated. 

(5) RAI is available within the MM Context of the UE. 



6.2 



MBMS Bearer Context 



The MBMS Bearer Context, which is referred to as MBMS Service Context in RAN, contains all information 
describing a particular MBMS bearer service and is created in each node involved in the delivery of the MBMS data. 

In MBMS multicast mode a MBMS Bearer Context is created in the SGSN and GGSN when the first MBMS UE 
Context is created in the node or when a downstream node requests it. The MBMS Bearer Context is statically 
configured in the BM-SC Proxy and Transport Function; how this is done is out of the scope of this specification. The 
MBMS Bearer Context is created in the lu mode BSC and in SRNC when a first MBMS UE Context is created in 
BSC/SRNC. MBMS Session Start procedure may create MBMS Bearer Context in a BSC/RNC which has no MBMS 
Bearer Context yet. 

In MBMS broadcast mode, an MBMS Bearer Context is created in the MME/SGSN, MBMS GW/GGSN and RAN as a 
result of the MBMS Session Start procedure. 

An MBMS Bearer Context, once created, can be in one of two states reflecting the bearer plane resource status of the 
corresponding MBMS bearer service. 
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No bearer plane resources required 
Standby 




Session Start Y i Session Stop 



Bearer plane resources required 

Figure 6: MBMS Bearer Context State Model 

'Active' reflects the state of an MBMS Bearer Context in which bearer plane resources are required in the network for 
the transfer of MBMS data. This state is maintained as long as there is a corresponding MBMS session ongoing. 

'Standby' reflects the state of an MBMS Bearer Context in which no bearer plane resources are required in the network 
for the transfer of MBMS data. This state is maintained as long as there is no corresponding MBMS session ongoing. 

In MBMS broadcast mode, the MBMS Bearer Context is always implicitly in state 'active' (since it is created as a result 
of an MBMS Session Start procedure) and does not use the MBMS Bearer Context State Model in Figure 6. 

The content of the MBMS Bearer Context is described in Table 2. 
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Table 2: MBMS Bearer Context for GPRS 



Parameter 


Description 


RAN 


SGSN 


GGSN 


BIVI-SC 


Multicast/broadcast 
mode 


MBMS bearer service in broadcast or multicast mode 


X 


X 


X 


X 


IP multicast address( 
multicast mode only) 


IP multicast address identifying the MBMS bearer 
described by this MBMS Bearer Context. 


X 


X 


X 


X 


APN 

(multicast mode only) 


Access Point Name on which this IP multicast address 
is defined. 


X 


X 


X 


X 


IMG! 


Temporary Mobile Group Identity allocated to the 
MBMS bearer service. 


X 


X 


X 


X 


Flow Identifier 
(broadcast mode 
only) 


Location dependent subflow of the MBMS bearer 
service. When present, the Flow Identifier together with 
the TMGI uniquely identify the MBMS Bearer Context. 




X 

(note 1 ) 


X 

(note 1 ) 


X 

(note 1 ) 


GGSN TEID-G 


Tunnel Endpoint Identifier of GGSN for control plane. 




X 






GGSN IP Address for 
Control Plane in use 


The IP address of the GGSN used for the control plane. 




X 

(note 4) 






State 


State of bearer plane resources ('standby' or 'active') 


X 


X 


X 


X 


Required MBMS 
Bearer Capabilities 
(multicast mode only) 


Minimum bearer capabilities the UE needs to support 




X 


X 


X 


QoS 


Quality of Service required for the MBMS bearer 
service. 


X 


X 


X 


X 


MBMS Service Area 


Area over which the MBMS bearer service has to be 
distributed. 


X 


X 


X 


X 


List of downstream 
nodes 


List of downstream nodes that have requested the 
MBMS bearer service and to which notifications and 
MBMS data have to be forwarded. 




X 

(note 5) 


X 

(notes 3, 
4,6) 


X 


Number of UEs 
(multicast mode only) 


Number of UEs hosted by the node that have joined the 
multicast MBMS bearer service. 




X 


X 




List of PMM- 
CONNECTED UEs 


List of PMM-CONNECTED UEs which have activated 
an MBMS service. 


x^' 








List of RAs 
(multicast mode only) 


List of RAs, each of which contains at least one UE that 
has joined the MBMS bearer service. 


X" 


X^' 






IP multicast and 
Source address for 
distribution 


IP addresses identifying the SSM channel used for user 
plane distribution on the backbone network 


X 


X 


X 




MBMS HC indicator 


Flag set by BM-SC if it is using compressed header for 
the payload. 




X 


X 


X 


NOTE 1 : It is an optional parameter. 

NOTE 2: It is available only for UTRAN, not for GERAN. 

NOTE 3: For GGSN, the list at least includes the couples of the SGSN IP addresses and TElDs for control plane, and 

the couples for user plane. 
NOTE 4: GSN that supports both IPv4 and IPv6 address types, stores only the IP address in use. 
NOTE 5: For SGSN, the list includes the registered DRNC. 
NOTE 6: The GGSN shall include SGSN Address for user data and TEID-U for downstream SGSNs that do not accept 

the IP multicast backbone distribution. 
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Table 3: MBMS Bearer Context for EPS (E-UTRAN/UTRAN) broadcast mode only 



Parameter 


Description 


RAN 


IVIME/ 
SGSN 


MBIVIS- 
GW 


BM-SC 


MBMS GW TEID-C 


Tunnel Endpoint Identifier of MBMS GW for control 
plane. 




X 






TMGI 


Temporary Mobile Group Identity allocated to the 
MBMS bearer service. 


X 


X 


X 


X 


Flow Identifier 


Location dependent subflow of the MBMS bearer 
service. When present, the Flow Identifier together with 
the TMGI uniquely identify the MBMS Bearer Context. 




X 

(note1) 


X 

(note1) 


X 

(note1) 


MBMSGW IP 
Address for Control 
Plane in use 


The IP address of the MBMS GW used for the control 
plane. 




X 

(note 2) 






MBMSGW IP 
Address for User 
Plane in use 


The IP address of the MBMS GW used for the user 
plane. 




X 

(note 2) 






C-TEID 


Common Tunnel Endpoint Identifier of MBMS GW for 
user plane 


X 




X 




OoS 


Quality of Service required for the MBMS bearer 
service. 


X 


X 


X 


X 


MBMS Service Area 


Area over which the MBMS bearer service has to be 
distributed. 


X 


X 


X 


X 


List of downstream 
nodes 


List of downstream nodes that have requested the 
MBMS bearer service and to which notifications 




X 

(note S) 


X 

(note 4) 


X 


IP multicast and 
Source address for 
distribution 


IP addresses identifying the SSM channel used for user 
plane distribution on the backbone network 


X 


X 


X 




MBMS HC indicator 


Flag set by BM-SC if it is using compressed header for 
the payload. 




X 

(note 5) 




X 

(note 5) 


N0TE1 
NOTE 2 
NOTES 
NOTE 4 
NOTES 


It is an optional parameter. 

MBMS GW that supports both IPv4 and IPv6 address types, stores only the IP address in use. 

For SGSN, the list includes the registered DRNG. 

For MBMS GW, the list at least includes the couples of the SGSN IP addresses and TElDs for control plane. 

Header Compression only supported for UTRAN for this Release. 



Editor's Note: Additional parameters may be included as work progresses. 

6.3 Quality-of-Service 

6.3.1 Quality-of-Service for GPRS 

It shall be possible for the network to control quality-of-service parameters for sessions of multicast and broadcast 
MBMS bearer services. All QoS attributes related to the UMTS bearer service described in TS 23.107 [3] are applicable 
to MBMS bearer services. Compared to point-to-point bearer services the following limitations exist; 

For traffic class, only the background and streaming classes shall be supported. 

For SDU error ratio, only higher values are supported, i.e. the values describing higher numbers of lost or 
corrupted SDUs (actual values are for the background and streaming classes are 10"^ and 10"'). 

For maximum bit-rate, see the values described in TS 22.246 [6]. 

For Guaranteed bit rate of the Streaming Traffic Class: depending on radio resource usage by other services, 
some cells of the MBMS Service Area may not have sufficient resources available for a MBMS Session. The 
RAN may decide not to establish RB in cells where requested resources are not available. The RAN does not 
reject a MBMS Session Start Request message even if one or more cells do not have enough resources to 
establish radio bearers. 

MBMS bearer services of background class are best suited for the transport of MBMS user services such as messaging 
or downloading. Buffering, shaping schemes and packet dropping may be applied to the traffic flow to adapt to the 
available resources and changing network conditions. The total transfer time is not critical for background class bearer 
services since the content must normally have been received in totality and stored in the UE before the user can access 
it. 
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MBMS bearer services of streaming class are best suited for the transport of MBMS user services such as streaming. As 
for point-to-point bearer services, the network should minimise the packet transfer delay of streaming class bearer 
services as far as possible. Packet dropping should be the preferred traffic conditioning action applied to the traffic flow 
to adapt to the available resources. 

The principle difference between background and streaming classes for MBMS is the support of a guaranteed bit-rate in 
the streaming case. No indication is provided to the UE in cases where the RAN cannot provide the requested QoS. As a 
result, some UEs may not receive the MBMS session or parts of it. For background class, the RAN may continue to 
distribute data in congestion conditions but at potentially high packet loss rates, therefore the MBMS user service will 
have to provide sufficient redundancy within the data to be able to cope with the high packet loss. 

MBMS user services that would normally use MBMS bearer services of background class may however decide to use a 
streaming class MBMS bearer service if the MBMS user service cannot cope with high packet loss. 

The Allocation and Retention Priority of the MBMS bearer service allows for prioritisation between MBMS bearer 
services, and between MBMS bearer services and non MBMS bearer services. 

As the MBMS bearer service transfers data to many UEs in parallel and because of the lack of feedback channel on 
radio level low SDU error ratios are difficult to achieve. When the resulting packet error ratio is not suitable for the 
MBMS user service or when prevention of data loss is required, an MBMS user service may perform retransmission of 
MBMS data over a point-to-point PDP context. 

6.3.2 Quality-of-Service for EPS 

It shall be possible for the network to control quality-of-service parameters for sessions of broadcast MBMS bearer 
services. All EPS QoS attributes related to the EPS bearer service are applicable to MBMS bearer services. 

For EPS, only GBR MBMS service is defined and the MBMS bearer service QoS includes the parameters QCI, ARP, 
GBR and MBR (TS 23.401 [16]). 

Each GBR MBMS bearer service is associated with the following MBMS bearer level QoS parameters: 

- QoS Class Identifier (QCI); 
Allocation and Retention Priority (ARP); 

- Maximum Bit Rate (MBR); 

- Guaranteed Bit Rate (GBR). 

Similar to point-to-point EPS bearers, the MBR of a particular GBR bearer service shall be set equal to the GBR. 

NOTE: UE-AMBR and APN-AMBR do not apply to MBMS bearer services. 

Compared to point-to-point bearer services the following limitations exist: 

For Guaranteed bit rate: depending on radio resource usage by other services, some cells of the MBMS Service 
Area may not have sufficient resources available for a MBMS Session. The RAN may decide not to establish RB 
in cells where requested resources are not available. The RAN does not reject a MBMS Session Start Request 
message even if one or more cells do not have enough resources to establish radio bearers. 

GBR MBMS bearer services are best suited for the transport of MBMS user services where a constant bit rate is needed. 
As for point-to-point bearer services, the network should comply with the transfer delay for GBR QCI's 
(TS 23.203 [23]). Packet dropping should be the preferred traffic conditioning action applied to the traffic flow to adapt 
to the available resources. The BM-SC ensures that the bit rate is not larger than the MBR. There is no radio aware flow 
shaping in the BM-SC. 

The Allocation and Retention Priority of the MBMS bearer service allows for prioritisation between MBMS bearer 
services, and between MBMS bearer services and non MBMS bearer services at MBMS bearer service establishment. 
The Allocation and Retention Priority does not apply to MBMS bearer service for E-UTRAN. 

When the MBMS bearer service experience a packet error ratio which is not suitable for the MBMS user service or 
when prevention of data loss is required, an MBMS user service may perform retransmission of MBMS data over a 
point-to-point PDP context or PDN connection. 
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6.3.3 MBMS QoS distribution tree 

MBMS data will be distributed to multiple users through a MBMS distribution tree that can go through many 
BSCs/RNCs, many SGSNs and one or more GGSNs. Furthermore some bearer resources may be shared between many 
users accessing the same MBMS bearer service in order to save resources. As a result, each branch of a MBMS 
distribution tree shall be established with the same QoS. 

MBMS distribution tree shall have the same QoS for all its branches. 

When a branch of the MBMS distribution tree has been created, it is not possible for another branch (e.g. due to arrival 
of a new UE or change of location of a UE with removal of a branch and addition of a new one) to impact the QoS of 
already established branches. 

There is no QoS (re-)negotiation between network elements (e.g. between RNC and SGSN). This implies that some 
branches may not be established if QoS requirement cannot be accepted by the concerned network node. 

6.4 Temporary Mobile Group Identity 

Temporary Mobile Group Identity (TMGI) is used for MBMS notification purpose. The BM-SC allocates a globally 
unique TMGI per MBMS bearer service. The structure of the TMGI is defined in TS 23.003 [13]. 

For Multicast MBMS bearer services the TMGI is transmitted to UE via the MBMS Multicast Service Activation 
procedure. For Broadcast Service the TMGI can be obtained via service announcement see " Service Announcement". 

The TMGI is a radio resource efficient MBMS bearer service identification, which is equivalent to the MBMS bearer 
service identification consisting of IP multicast address and APN. 

6.5 IP Multicast distribution 

6.5.1 General 

For GPRS in GGSN or for EPS in MBMS GW it shall by configuration be possible to enable distribution of MBMS 
payload by using IP Multicast in the backbone network. IP Multicast distribution is done from GGSN to RNC 
downstream nodes or from MBMS GW to eNodeB or RNC downstream nodes. The Source Specific Multicast (SSM) 
service model shall be used by nodes and routers as specified in RFC 4607 [21] and RFC 4604 [22]. 

6.5.2 IP Multicast distribution for GERAN lu-mode and UTRAN for GPRS 

Fallback to legacy point-to-point distribution is done for RNC nodes which do not support IP Multicast distribution. 

NOTE: Support of fallback assumes the corresponding SGSNs have user plane functionality. 

The GGSN chooses an IP Multicast address for distribution and a Source address as well as a common TEID-U 
(C-TEID). The proposed IP Multicast and Source address for distribution and the C-TEID is indicated by the GGSN to 
the downstream SGSNs at Session Start. The SGSN forwards the request to the downstream RNC (and BSC in lu 
mode) at Session Start. The RNC may accept or reject the proposed IP Multicast distribution in the MBMS Session 
Start Response to the SGSN. If accepted the RNC shall report the channel (IP Multicast and Source address) to the 
backbone in order to join the bearer service multicast distribution. At Session Stop the RNC shall correspondingly 
report to the backbone in order to leave the bearer service multicast distribution. 

If one or more downstream RNC nodes do not accept IP Multicast distribution, the SGSN will establish a normal 
MBMS point-to-point GTP-U tunnel to related RNCs and a point-to-point GTP-U tunnel to the GGSN. The SGSN does 
not respond to the GGSN until it has received responses from all RNCs. The SGSN shall indicate to the GGSN if IP 
Multicast distribution is accepted (by one or more RNCs) and it shall also indicate if normal MBMS point-to-point 
distribution is required (by one or more RNCs). The SGSN will also establish a normal MBMS point-to-point GTP-U 
tunnel to GGSN if there are BSCs in Gb mode in the MBMS distribution tree. 

The RNC node shall indicate to SGSN if IP Multicast distribution is accepted in the Session Start Response. If this 
indication is missing, the SGSN node shall treat the RNC node as not accepting IP Multicast distribution and use 
unicast distribution. 
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IP Multicast distribution is only used within a PLMN. In the roaming case the GGSN establishes normal MBMS point- 
to-point GTP-U tunnels to SGSNs/RAN nodes in other networks. 

GGSN shall assign IP Multicast addresses used for MBMS distribution according to RFC 4607 [21]. When several 
GGSN are used for MBMS payload distribution, the used IP Multicast addresses and common TEIDs shall be 
coordinated by configuration. Clashes between common TEIDs allocated by GGSN and TEIDs allocated by RNC 
should be avoided by coordinated TEID ranges. 

The GTP-U Error Indication mechanism shall be disabled for MBMS bearers using IP Multicast distribution. The 
receiving node controls itself what is received using the IGMPv3/MLDv2 protocol, RFC 4604 [22]. 

The MBMS payload with the synchronization information received from the BM-SC included, shall be distributed by 
the GGSN with IP Multicast to the RNC. The synchronization information is used in the radio interface for the user data 
transmission synchronization across the RNCs as described in TS 25.346 [10]. It is up to RAN configurations whether 
the inter-RNC MBMS combining/MBSFN operation mode is used during the MBMS payload delivery. 

6.5.3 IP Multicast distribution for E-UTRAN and UTRAN for EPS 

The MBMS GW chooses an IP Multicast address for distribution. The proposed IP Multicast and Source address for 
distribution is indicated by the MBMS GW to the downstream MMEs and/or SGSNs at Session Start. The MME/SGSN 
forwards the request to the downstream eNodeB/RNC at Session Start. 

In the UTRAN case, the RNC may accept or reject the proposed IP Multicast distribution in the MBMS Session Start 
Response to the SGSN. The RNC node shall indicate to SGSN if IP Multicast distribution is accepted in the Session 
Start Response. If accepted the RNC shall report the channel (IP Multicast and Source address) to the backbone in 
order to join the bearer service multicast distribution. At Session Stop the RNC shall correspondingly report to the 
backbone in order to leave the bearer service multicast distribution. If one or more downstream RNC nodes do not 
accept IP Multicast distribution, the SGSN will establish a normal MBMS point-to-point GTP-U tunnel to related RNCs 
and a point-to-point GTP-U tunnel to the MBMS GW. The SGSN does not respond to the MBMS GW until it has 
received responses from all RNCs or until a configurable time has elapsed (e.g. with a recommended default of 
5 seconds). The SGSN shall indicate to the MBMS GW if IP Multicast distribution is accepted (by one or more RNCs) 
and it shall also indicate if normal MBMS point-to-point distribution is required (by one or more RNCs). The RNC 
node shall indicate to SGSN if IP Multicast distribution is accepted in the Session Start Response. If this indication is 
missing, the SGSN node shall treat the RNC node as not accepting IP Multicast distribution and use unicast distribution. 

IP Multicast distribution is only used within a PLMN. 

MBMS GW shall assign IP Multicast addresses used for MBMS distribution according to RFC 4607 [21]. When several 
MBMS GWs are used for MBMS payload distribution, the used IP Multicast addresses shall be coordinated by 
configuration. Clashes between common TEIDs allocated by MBMS GW and TEIDs allocated by eNodeB/RNC should 
be avoided by coordinated TEID ranges. 

The receiving node controls itself what is received using the IGMPv3/MLDv2 protocol RFC 4604 [22]. 

The MBMS payload with the synchronization information received from the BM-SC shall be distributed by the MBMS 
GW with IP Multicast to the eNodeB/RNC. The synchronization information is used in the radio interface for the user 
data transmission synchronization across the eNodeBs and RNCs as described in TS 25.346 [10]. It is up to RAN 
configurations whether the inter-RNC MBMS combining/MBSFN operation mode is used during the MBMS payload 
delivery. 

Mobility between cells may cause limited MBMS data loss towards the UE. Therefore, MBMS user services should be 
able to cope with potential data loss caused by UE mobility. 



7 Architectural Aspects of MBMS User Services 

MBMS bearers may be used in numerous ways to provide different types of applications. MBMS user services employ 
MBMS bearers and possibly point-to-point bearers in order to provide application data in an efficient manner. This 
section is used to discuss different aspects of MBMS user services that directly relate to the usage of MBMS and point- 
to-point bearers. This section is not intended to deal with the architecture and interfaces of MBMS user services. 
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7.1 Alternative User Service Support 

For many MBMS services, it will be necessary to provide alternative means for the UE to access the service without 
using MBMS bearer capabilities. This is required, for example, after completion of the MBMS session for a file 
download to permit errors in the file to be corrected; to permit the network to charge for a successful download; to pass 
a decrypt key to the UE; etc. It may also be useful in cases where all or part of an MBMS transmission has been missed 
due to the UE being out of coverage, switched off, etc. 

Care is needed to ensure that such alternative access mechanisms do not create traffic that overloads the network (radio, 
RNC, BSC, SGSN, GGSN and BM-SC). In the case that such alternative access requires direct interaction between the 
UE and a network server, one way for this load to be distributed is for the BM-SC to distribute to each UE, at activation 
time, one or more server addresses (from a group of addresses), along with parameter(s) that are used to generate a 
random time dispersion of the requests. 

7.2 Avoid overload in SGSN, GGSN and BIVI-SC caused by 
Joining 

For Joining that is triggered by a service announcement (e.g. CBS or MBMS), then the service announcement needs to 
be able to contain parameters to help avoid overload in the SGSN, GGSN and BM-SC. The UE uses the defined 
parameters in the service announcement to randomly select the time at which to join the service. Hence the BM-SC 
needs to be able to generate the parameters and needs to be able to get them sent to the UE in the service announcement. 

7.3 Access aspects of IVIBIVIS user services 

In networks with multiple accesses, e.g. GERAN and UTRAN for GPRS, users may in some situations experience 
problems in receiving MBMS services. These situations include: 

an operator that has chosen to provide a service on one access only (e.g. only on GERAN), and where a UE is 
camping on the wrong access (i.e. on UTRAN in the previous example) when an MBMS session is started. This 
UE may miss the MBMS content, as the MBMS architecture doesn't provide any mechanism for paging 
coordination, etc. 

an operator that has chosen to provide a service with different QoS levels e.g. on GERAN and UTRAN (see 
clause 5.1.5.2). A UE that is changing access type during an ongoing MBMS session may not be able sort the 
situation out and receive the MBMS content correctly. 



8 IVIBIVIS Procedures 

8.1 MBMS Notification 

8.1 .1 lu mode notification (UTRAN and GERAN) for GPRS 

When an MBMS Session starts, UEs interested in the MBMS bearer service (PMM-CONNECTED UEs and PMM- 
IDLE UEs) shall be notified. 

MBMS Session attributes such as Session Identifier and MBMS Service Area(s) are made available in all interested 
RNCs during the Session Start procedure. 

For radio efficiency reasons, the UTRAN may select on a per cell basis whether to establish point-to-point or point-to- 
multipoint links for the distribution of MBMS data to the UEs. 

In order to perform this selection, the UTRAN requests a proportion of UEs to move to PMM-CONNECTED mode by 
means of MBMS notification sent in the MBMS service Area. 

The exact number of UEs moved to PMM-CONNECTED mode is a decision of the RAN node. It is not necessary for 
all UEs to move to PMM-CONNECTED mode in order for the RAN to decide to use point-to-multipoint, other UEs 
may remain in PMM-IDLE state. This is a UTRAN choice (based on Radio Resource Management criteria). 
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Following the decision to set up point-to-point or point- to -multipoint links, the number of UEs that need to be 
maintained in PMM-CONNECTED mode or moved to PMM-IDLE mode for MBMS data reception is also a decision 
of the RAN node. 



8.1 .2 A/Gb mode notification (GERAN) 



When an MBMS Session starts, UEs interested in the MBMS bearer service and that are in READY or STANDBY 
states shall be notified. The MBMS notification triggers detection or counting of UEs per cell for selection of the most 
appropriate MBMS radio bearer. 

MBMS Session attributes such as Session Identifier, MBMS Service Area, QoS are made available in all interested 
BSCs that are connected to a registered SGSN by the Session Start procedure. 



8.2 



MBMS Multicast Service Activation 



The MBMS multicast service activation procedure registers the user in the network to enable the reception of data from 
a specific multicast MBMS bearer service. The activation is a signalling procedure between the UE and the network. 
The procedure establishes MBMS UE contexts in UE, SGSN and GGSN and lu mode BSC/RNC for each activated 
multicast MBMS bearer service comparable to regular PDP contexts. 



UE 



RAN 



l.PDPConte 



2.TGMP.Tnin 



5. Request MB]V S Context Activi tion 



6. Activate MB]\[S Context Request 



8. Security Functions 



15. 



SGSN 



t Activation 



9. Invoke Trace 



provision of MBN S 
Context to RAN 



16. Invoke Trac; 



17. Activate MI SMS Context Accept 



GGSN 



4a. MBMS Notificati( n Request 



4b. MBMS Notificati( 

► 



7. MBMS Notificatic n Reject Request 



7. MBMS Notificatic n Reject Response 



BM-SC 



3. MBMS Authorization Request 



3. MBMS Authorization Response 



n Response 



GGSN 



10. Create MBMS Context Request 



13. Create MBMS C|ontext Response 
ion Request 
ion Response 



14. MBMS Registra 
- > 



14. MBMS Registra 

ue"! 



11. MBMS Authorization Reque) I 



11. MBMS Authorization Respot se 



12.MBMS Registration Request 
12. MBMS Registration Responsfe 



Figure 7: The activation of an IVIBIVIS multicast service 



£75/ 



3GPP TS 23.246 version 1 0.0.0 Release 1 36 ETSI TS 1 23 246 V1 0.0.0 (201 1 -03) 

1 . The UE activates a general purpose PDP context if one is not already established. 

2. The UE sends an IGMP (IPv4) or MLD (IPv6) Join message over the default PDP context to signal its interest in 
receiving a particular multicast MBMS bearer service identified by an IP multicast address. 

3. The GGSN sends an MBMS Authorization Request seeking authorization for the activating UE to receive data. 
The MBMS Authorization Request may include trace information (Additional MBMS Trace Info), if activated. 
The authorization decision, which may be based on subscription data in the BM-SC, Membership function is 
provided in the MBMS Authorization Response together with the APN to be used for creation of the MBMS UE 
context. If the MBMS Authorization Response indicates that the UE is not authorized to receive the MBMS data 
the process terminates with no additional message exchange. 

4a. The GGSN sends an MBMS Notification Request (IP multicast address, APN, Linked NSAPI) to the SGSN. 
Linked NSAPI is set equal to the NSAPI of the PDP context over which the Join request was received. The IP 
multicast address is the one requested by the UE in the Join request. The APN may be different from the APN to 
which the default PDP context has been activated. In any case, the APN may resolve to a GGSN that is different 
from the GGSN receiving the IGMP/MLD Join request. 

4b. The SGSN sends a MBMS Notification Response (Cause) to the GGSN that sent the MBMS Notification 

Request, where Cause shall indicate whether or not the MBMS context activation will proceed. Upon reception 
of the response message with Cause indicating unsuccessful operation the GGSN should not send any further 
MBMS Notification Request messages. The procedure is then terminated. 

5. The SGSN sends a Request MBMS Context Activation (IP multicast address, APN, Linked NSAPI, TI) to the 
UE to request it to activate an MBMS UE Context. Linked NSAPI allows the UE to associate the MBMS UE 
Context with the PDP context over which it sent the IGMP/MLD Join message in step 2. TI was chosen by the 
SGSN and contains a value not used by any other activated PDP context and MBMS UE context for this UE. 

6. The UE creates an MBMS UE context and sends an Activate MBMS Context Request (IP multicast address, 
APN, MBMS_NSAPI, MBMS bearer capabilities) to the SGSN. The IP multicast address identifies the MBMS 
multicast service, which the UE wants to join/activate. An APN may indicate a specific GGSN. The MBMS 
bearer capabilities indicate the maximum QoS the UE can handle. The MBMS_NSAPI was chosen by the UE 
and contains a value not used by any other activated PDP context and MBMS UE context for this UE. If the 
SGSN has the MBMS Bearer Context information for this MBMS bearer service, the SGSN should verify the 
UE's MBMS bearer capabilities. If the SGSN determines that the UE's MBMS bearer capabilities are less than 
the Required MBMS Bearer Capabilities, it shall reject the request for activation of an MBMS context with an 
appropriate cause. 

7. If the MBMS UE Context was not established, the SGSN sends a MBMS Notification Reject Request (Cause) to 
the GGSN that sent the MBMS Notification Request, where Cause shall indicate the reason why the MBMS UE 
Context could not be established. The GGSN then sends a MBMS Notification Reject Response back to the 
SGSN. This should prevent further sending of MBMS Notification Request messages. The procedure is then 
terminated. 

8. Security Functions may be performed, e.g. to authenticate the UE. 

9. In A/Gb mode and if BSS trace is activated, the SGSN shall send an Invoke Trace (Trace Reference, Trace Type, 
Trigger Id, and OMC Identity) message to the BSS. Trace Reference, and Trace Type are copied from the trace 
information received from the HLR or OMC. 

10. The SGSN creates an MBMS UE context and sends a Create MBMS Context Requests (IP multicast address, 
APN, MBMS_NSAPI, IMSI, MSISDN, RAI, IMEI-SV, RAT Type, MS Time Zone, CGI/SAI, Trace Reference, 
Trace Type, Trigger Id, OMC Identity , Additional MBMS Trace Info) to the GGSN. The SGSN shall include 
Trace Reference, Trace Type, Trigger Id, and OMC Identity if GGSN trace is activated. The SGSN shall include 
Additional MBMS Trace Info if BM-SC trace is activated. The SGSN shall copy Trace Reference, Trace Type, 
and OMC Identity from the trace information received from the HLR or OMC. The inclusion of CGI/SAI shall 
be according rules detailed in sub-clause IS.Lla in TS 23.060 [15]. 

n. The GGSN sends an MBMS Authorization Request (IMSI, MSISDN, RAI, IMEI-SV, RAT Type, MS Time 
Zone, CGI/SAI, Additional MBMS Trace Info) seeking authorization for the activating UE. The GGSN shall 
include Additional MBMS Trace Info if BM-SC trace is activated. The CGI/SAI is included, if available. The 
authorization decision is provided in the MBMS Authorization Response. The BM-SC creates an MBMS UE 
Context. 
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12. If the GGSN does not have the MBMS Bearer Context information for this MEMS bearer service, the GGSN 
sends a MBMS Registration Request to the BM-SC. See clause "MBMS Registration Procedure". 

If no TMGl has been allocated for this MBMS bearer service, the BM-SC will allocate a new TMGl. This TMGI 
will be passed to GGSN and SGSN via the MBMS Registration Response message and further to UE via 
Activate MBMS Context Accept message. 

The BM-SC responds with a MBMS Registration Response containing the MBMS Bearer Context information 
for this MBMS bearer service and adds the identifier of the GGSN to the "list of downstream nodes" parameter 
in its MBMS Bearer Context. See clause "MBMS Registration Procedure". 

13. The GGSN creates an MBMS UE context and sends a Create MBMS Context Response to the SGSN. 

14. If the SGSN does not have the MBMS Bearer Context information for this MBMS bearer service, the SGSN 
sends a MBMS Registration Request to the GGSN. See clause "MBMS Registration Procedure". 

The GGSN responds with a MBMS Registration Response containing the MBMS Bearer Context information 
for this MBMS bearer service and adds the identifier of the SGSN to the "list of downstream nodes" parameter in 
its MBMS Bearer Context. See clause "MBMS Registration Procedure". 

15. The SGSN provides lu mode RAN with the MBMS UE Context(s) if at least one PS RAB is established for the 
UE. 

16. In lu mode and if trace is activated, the SGSN shall send an Invoke Trace (Trace Reference, Trace Type, Trigger 
Id, and OMC Identity) message to the RAN. Trace Reference, and Trace Type are copied from the trace 
information received from the HLR or OMC. 

NOTE: Step 16 is applied when the trace activation is triggered by means of signalling. Another alternative is the 
triggering of trace activation by the OMC. The details of both Trace Activation procedures are described 

in TS 32.422 [14]. 

17. The SGSN sends an Activate MBMS Context Accept (TMGI) to the UE. If it was not possible to verify the UE's 
MBMS bearer capabihties in Step 6, the UE's MBMS bearer capabilities shall be verified now b y the SGSN. If 
the SGSN determines that the UE's MBMS bearer capabilities are lower than the Required MBMS Bearer 
Capabilities the SGSN rejects the request for activation of an MBMS context indicating an appropriate cause and 
starts the deactivation of the already established MBMS UE contexts. 

8.2.1 Void 



8.3 MBMS Session Start Procedure 
8.3.0 General 

The BM-SC initiates the MBMS Session Start procedure when it is ready to send data. This is a request to activate all 
necessary bearer resources in the network for the transfer of MBMS data and to notify interested UEs of the imminent 
start of the transmission. 

Through this procedure, MBMS session attributes such as QoS, MBMS service Area, estimated session duration, are 
provided to the registered GGSN(s) and SGSN(s), to all BSCs/RNCs that are connected to a listed SGSN and to the 
registered MBMS GW(s) and MME(s). In addition the procedure allocates the bearer plane to all registered GGSNs, all 
registered SGSNs and all registered MBMS GWs, to BSCs/RNCs and E-UTRAN that respond to the session start 
request message. If IP multicast distribution of MBMS user plane data to E-UTRAN/UTRAN is supported, the MBMS- 
GW allocates a IP Multicast address which together with the IP address of the multicast source (i.e. MBMS GW) and 
the C-TEID are provided to the eNodeB via MME and to the RNC via SGSN in this procedure. 

After sending the Session Start Request message the BM-SC waits for a configurable delay (time to MBMS data 
transfer) before sending MBMS data. This delay should be long enough to avoid buffering of MBMS data in entities 
other than the BM-SC, i.e. the delay should allow the network to perform all procedures required to enable MBMS data 
transfer before the BM-SC sends MBMS data. For example notification of UEs and radio bearer establishment should 
be performed before MBMS data arrive in the RAN. The delay may be in the region of multiple seconds or tens of 
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seconds. It may be useful for the BM-SC to be able to configure different delays for MBMS bearer services on 2G, 3G 
and E-UTRAN, respectively. 

8.3.1 MBMS Session Start Procedure for GERAN and UTRAN for GPRS 

For multicast MBMS bearer services the registration of SGSNs and GGSNs is initiated by MBMS multicast Service 
Activation procedures, Inter SGSN Routeing Area Update procedures, Inter SGSN Serving RNS Relocation procedure 
and performed by MBMS Registration procedures. The GGSN keeps track of the registered SGSNs in the list of 
downstream nodes. 

For broadcast MBMS bearer services the list of downstream nodes of BM-SC and GGSN are achieved in the following 
ways: 

The list of downstream nodes for GGSN will be sent from the BM-SC to the GGSN in the Session Start Request. 

Normally, the GGSN contained in the "list of downstream nodes" for BM-SC is the default GGSN (or two for 
resilience). 

The overall Session Start procedure is presented in the following figure: 
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Figure 8a: Session Start procedure for GERAN and UTRAN for GPRS 

The BM-SC Session and Transmission function sends a Session Start Request message to indicate the impending 
start of the transmission and to provide the session attributes (TMGI, Flow Identifier (Broadcast only), QoS, 
MBMS service Area, Session identifier, estimated session duration, broadcast/multicast, list of downstream 
nodes for GGSN (Broadcast only), time to MBMS data transfer, MBMS HC indicator (if header compression is 
used for MBMS payload), ...) and the 2G/3G indicator. The message is sent to the BM-SC Proxy and Transport 
function, which then forwards it to the GGSNs listed in the "list of downstream nodes" parameter of the 
corresponding MBMS Bearer Context. The BM-SC Proxy and Transport function sets the state attribute of its 
MBMS Bearer Context to 'Active'. For a broadcast MBMS bearer service the GGSN creates an MBMS bearer 
context. In broadcast mode, the BM-SC may start multiple sessions for the same MBMS bearer service 
(identified by the TMGI) but with different content. If so, a Flow Identifier is included in the Session Start 
Request to identify the different sub-sessions and the associated MBMS Service Areas shall not overlap. The 
GGSN stores the session attributes and the list of downstream nodes in the MBMS Bearer Context, sets the state 
attribute of its MBMS Bearer Context to 'Active' and sends a Session Start Response message to the BM-SC. 
Proxy and Transport function which forwards it to the BM-SC Session and Transmission function. The BM-SC 
Proxy and Transport function copies Session Start Requests to the BM-SC Membership function for charging 
purposes. 

The GGSN sends an MBMS Session Start Request message containing the session attributes (TMGI, Flow 
Identifier (Broadcast only), QoS, MBMS service Area, Session identifier, estimated session duration, 
broadcast/multicast, time to MBMS data transfer, IP Multicast and Source addresses for backbone distribution, 
common TEID-U, MBMS HC indicator, ...) and the 2G/3G indicator to the SGSNs hsted in the "hst of 
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downstream nodes" parameter of the corresponding MBMS Bearer Context. For a broadcast MBMS bearer 
service the SGSN creates an MBMS bearer context. The SGSN stores the session attributes and the 2G/3G 
indicator in the MBMS Bearer Context, sets the state attribute of its MBMS Bearer Context to 'Active'. If one or 
more of the downstream nodes accepts the Session Start and the proposed IP Multicast and Source address for 
backbone distribution and the proposed C-TEID, the SGSN includes an indication that IP Multicast distribution 
is accepted in the MBMS Session Start Response message to GGSN. If one or more of the downstream nodes 
does not accept the proposed IP Multicast and Source address for backbone distribution or the proposed C-TEID 
or if there are downstream BSCs in Gb mode connected to the SGSN, the SGSN falls back to normal point-to- 
point MBMS bearer establishment for these nodes and responds with an MBMS Session Start Response message 
providing the TEID for bearer plane that the GGSN shall use for forwarding the MBMS data. Otherwise if all 
nodes accept multicast, the SGSN returns the C-TEID and the IP Multicast distribution address in the Session 
Start Response message. The GGSN shall initiate IP Multicast distribution if at least one of the SGSNs indicates 
it has accepted IP Multicast distribution. For MBMS bearer service a SGSN receiving multiple MBMS Session 
Start Request messages establishes only one bearer plane with one GGSN. 

3. The SGSN sends an MBMS Session Start Request message including the session attributes (TMGI, QoS, 
MBMS service Area, Session identifier, estimated session duration, broadcast/multicast, time to MBMS data 
transfer, Hst of RAs, MBMS HC indicator, ...) to each BSC and/or each RNC that is connected to this SGSN. 
When the message is sent to an RNC/BSC in lu mode, the IP Multicast and Source address for backbone 
distribution and C-TEID shall also be included if received from the GGSN. The 2G/3G indicator shall be used by 
the SGSN to determine whether the MBMS Session Start Request message is sent only to BSCs, or only to 
RNCs, or to both RNCs and BSCs. For a broadcast MBMS bearer service the BSC/RNC creates an MBMS 
Service Context. The BSC in lu mode/RNC stores the session attributes in the MBMS Service Context, sets the 
state attribute of its MBMS Service Context to 'Active'. If the RNC accepts the Session start and the proposed IP 
Multicast and Source address for backbone distribution and the proposed C-TEID the RNC sends an MBMS 
Session Start Response message to SGSN including an indication that IP Multicast distribution is accepted. If an 
RNC does not accept the proposed IP Multicast and Source address for backbone distribution (or the proposed 
C-TEID), the RNC falls back to normal point-to-point MBMS bearer establishment. A BSC in Gb mode which 
does not serve the MBMS Service Area need not store the session attributes. A BSC/RNC receiving multiple 
MBMS Session Start Request messages establishes only one bearer plane with one SGSN. 

3a If the BSC/RNC accepts IP Multicast distribution the BSC/RNC joins the multicast group in the IP backbone 
according to RFC 3376 [19], RFC 3810 [20] and RFC 4604 [22]. 

4. The BSC/RNC establishes the necessary radio resources for the transfer of MBMS data to the interested UEs. 
RAN resource set up can be scheduled according to the time to MBMS data transfer parameter. 

NOTE: The upstream node normally provides the MBMS Session Start Request message once per MBMS 
session to a downstream node. Due to "Intra Domain Connection of RAN Nodes to Multiple Core 
Network Nodes" however, a BSC/RNC may receive the MBMS Session Start Request message from 
several SGSNs. 

8.3.2 MBMS Session Start Procedure for E-UTRAN and UTRAN for EPS 

The Ust of downstream nodes of BM-SC and the list of MBMS control plane nodes (MMEs and SGSNs) of MBMS GW 
are achieved in the following ways: 

- The list of MBMS control plane nodes for MBMS GW will be sent from the BM-SC to the MBMS GW in the 
Session Start Request. 

Normally, the MBMS GW contained in the "list of downstream nodes" for BM-SC is the default MBMS GW (or two 
for resilience). 

The overall Session Start procedure is presented in the following figure: 
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Figure 8b: Session Start procedure for E-UTRAN and UTRAN for EPS 

1 . BM-SC sends a Session Start Request message to MBMS GW to indicate the impending start of the transmission 
and to provide the session attributes (TMGI, Flow Identifier, QoS, MBMS service Area, Session identifier, 
estimated session duration, list of MBMS control plane nodes (MMEs, SGSNs) for MBMS GW, access 
indicator, ...)• The message is sent to the MBMS GWs listed in the "downstream nodes" parameter of the 
corresponding MBMS Bearer Context in the BM-SC. The BM-SC may start multiple sessions for the same 
MBMS bearer service (identified by the TMGI) but with different content. If so, a Flow Identifier is included in 
the Session Start Request to identify the different sub-sessions and the associated MBMS Service Areas shall not 
overlap. The Access indicator indicates in which radio access types the MBMS service should be broadcasted, 
i.e. UTRAN, or E-UTRAN, or both. The Access indicator may be included in charging information generated by 
the MBSM GW. 

2. The MBMS GW responds with a Session Start Response message with information for BM-SC to send MBMS 
data to the MBMS GW. 

3. The MBMS GW creates an MBMS bearer context. The MBMS GW stores the session attributes and the list of 
MBMS control plane nodes in the MBMS bearer context and allocates a transport network IP multicast address 
and a C-TEID for this session. The MBMS GW sends a Session Start Request message including the session 
attributes (TMGI, Flow Identifier, QoS, MBMS service Area, Session identifier, estimated session duration, 
transport network IP Multicast Address, IP address of the multicast source, C-TEID, ...) to MMEs and/or SGSNs 
listed in the "list of MBMS control plane nodes" parameter after filtering the list using the Access indicator, thus 
ignoring entries not consistent with the Access indicator. 

4. The MME or SGSN creates an MBMS bearer context. The MME/SGSN stores the session attributes and sends a 
Session Start Request message including the session attributes (TMGI, QoS, MBMS service Area, Session 
identifier, estimated session duration, broadcast (for UTRAN only), transport network IP Multicast Address, IP 
address of the multicast source, C-TEID, ...) to E-UTRAN/UTRAN. 

For UTRAN, if one or more of the downstream nodes accepts the Session Start and the proposed IP Multicast 
and Source address for backbone distribution and the proposed C-TEID, the SGSN includes an indication that IP 
Multicast distribution is accepted in the MBMS Session Start Response message to MBMS GW. If one or more 
of the downstream nodes does not accept the proposed IP Multicast and Source address for backbone distribution 
or the proposed C-TEID, the SGSN falls back to normal point-to-point MBMS bearer establishment for these 
nodes and responds with an MBMS Session Start Response message providing the TEID for bearer plane that 
the MBMS GW shall use for forwarding the MBMS data. Otherwise if all nodes accept multicast, the SGSN 
returns the C-TEID and the IP Multicast distribution address in the Session Start Response message. The MBMS 
GW initiates IP Multicast distribution and/or point-to-point MBMS bearers depending on the responses from the 
SGSNs. 
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5. The E-UTRAN/UTRAN creates an MBMS bearer context. The E-UTRAN/UTRAN stores the session attributes, 
sets the state attribute of its MBMS Bearer Context to 'Active' (in UTRAN only) and responds the MME/SGSN 
to confirm the reception of the Session Start Request message. 

For UTRAN, if an RNC accepts the Session start and the proposed IP Muhicast and Source address for backbone 
distribution and the proposed C-TEID the RNC sends an MBMS Session Start Response message to SGSN 
including an indication that IP Multicast distribution is accepted. If an RNC does not accept the proposed IP 
Multicast and Source address for backbone distribution (or the proposed C-TEID), the RNC falls back to normal 
point-to-point MBMS bearer establishment. 

Editor's Note: It is PES whether MME can send Session Start to all E-UTRAN nodes controlled by that MME and 
rely on E-UTRAN to perform Service Area filtering. 

6. The MME/SGSN stores the session attributes and the identifier of the eNBs/RNCs as the "list of downstream 
nodes" parameter in its MBMS Bearer Context and responds to the MBMS GW. 

Editor's Note: It is FES if SGSN or MME need wait response from any, one or all UTRAN/E-UTRAN nodes and if 
SGSN and MME behave same way. 

7. The E-UTRAN/UTRAN establishes the necessary radio resources for the transfer of MBMS data to the 
interested UEs. 

8. If the E-UTRAN/UTRAN node accepts IP Multicast distribution, it joins the transport network IP multicast 
address (including the IP address of the multicast source) allocated by the MBMS GW, to enable reception of 
MBMS data. 

9. The BM-SC starts sending the MBMS data. 

10. MBMS GW function receives MBMS data. MBMS GW sends the MBMS data using IP multicast distribution 
towards all joined eNodeBs/RNCs. 



8.4 MBMS Registration Procedure 



The MBMS Registration is the procedure by which a downstream node informs an upstream node that it would like to 
receive session attributes and data for a particular MBMS bearer service in order to distribute it further downstream. 
This procedure builds up a distribution tree for the delivery of MBMS session attributes and data from the BM-SC to 
the UEs interested in the service. This procedure results in the set-up of a corresponding MBMS Bearer Context in the 
nodes along the distribution tree, but it does not result in the establishment of bearer plane which will be established by 
the Session Start procedure. 

The MBMS Registration procedure is initiated: 

- When the first MBMS UE Context for a particular MBMS bearer service is created in the SGSN or GGSN (see 
clause "MBMS UE Context") and the corresponding MBMS Bearer Context is not already established in the 
node; 

When an MBMS Registration Request for a particular MBMS bearer service is received from a downstream 
node but the corresponding MBMS Bearer Context is not established in the node; or 

When a DRNC detects that it hosts UEs interested in the MBMS bearer service. 

NOTE: The terms 'downstream' and 'upstream' refer to the topological position of one node with respect to 
another and relative to the direction of the MBMS data flow, i.e. from BM-SC to UE. 
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Figure 9: MBMS Registration procedure 

1. Wiien the DRNC detects that it hosts UEs interested in the MBMS bearer service, the DRNC sends a MBMS 
Registration Request message to its parent SGSN if not already done. How the RNC determines its parent SGSN 
is a matter of implementation. 

2. If the SGSN has no MBMS Bearer Context for an MBMS bearer service and the SGSN receives an MBMS 
Registration Request from an RNC for this MBMS bearer service, or if the first MBMS UE Context is created in 
the SGSN for an MBMS bearer service for which the SGSN has no corresponding MBMS Bearer Context, the 
SGSN creates an MBMS Bearer Context (in "Standby" state) and sends an MBMS Registration request (IP 
multicast address, APN) message to the GGSN. How the SGSN selects a GGSN is a matter of implementation; it 
may for instance be based on prior signalling related to a particular UE or via APN resolution. 

3. If the GGSN has no MBMS Bearer Context for an MBMS bearer service and the GGSN receives an MBMS 
Registration from an SGSN for this MBMS bearer service, or when the first MBMS UE Context is created in the 
GGSN for an MBMS bearer service for which the GGSN has no MBMS Bearer Context, the GGSN creates an 
MBMS Bearer Context (in "Standby" state) and sends a Registration Request (IP multicast address, APN) 
message to the BM-SC. Proxy and Transport function The exact nature of the signalling between GGSN and 
BM-SC via Gmb interface is specified in TS 29.061 [4]. 

4. Upon reception of an MBMS Registration Request from a GGSN, the BM-SC Proxy and Transport function 
adds the identifier of the GGSN to the "list of downstream nodes" parameter in its MBMS Bearer Context and 
responds with a MBMS Registration Response (TMGI, Required Bearer Capabilities) message. The exact nature 
of the signalling between GGSN and BM-SC via Gmb interface is specified in TS 29.061 [4]. If the MBMS 
Bearer Context is in the 'Active' state, the BM-SC initiates the Session Start procedure with the GGSN, as 
described in clause "MBMS Session Start Procedure". 

5. If the GGSN receives a Registration Request from the SGSN in step 2, the GGSN: 

adds the identifier of the SGSN to the "list of downstream nodes" parameter in its MBMS Bearer Context, 

responds with an MBMS Registration Response (TMGI, Required Bearer Capabilities) message, and 

if the MBMS Bearer Context is in the 'Active' state, initiates the Session Start procedure with the SGSN, as 
described in clause "MBMS Session Start Procedure". 

6. If the SGSN received MBMS Registration Request from the DRNC in step 1, the SGSN: 

adds the identifier of the RNC to the "list of downstream nodes" parameter in its MBMS Bearer Context, 

responds with an MBMS Registration Response message, and 

if the MBMS Bearer Context is in the 'Active' state, initiates the Session Start procedure with the DRNC, as 
described clause "MBMS Session Start Procedure". 
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8.5 MBMS Session Stop Procedure 

8.5.0 General 

The BM-SC Session and Transmission function initiates the MBMS Session Stop procedure when it considers the 
MBMS session to be terminated. The session is typically terminated when there is no more MBMS data expected to be 
transmitted for a sufficiently long period of time to justify a release of bearer plane resources in the network. For 
GERAN and UTRAN for GPRS, the procedure is propagated to all SGSNs and GGSNs that are registered for the 
corresponding MBMS bearer service and to BSCs/RNCs that have an established lu bearer plane with an SGSN. For 
E-UTRAN and UTRAN for EPS, the procedure is propagated to all MBMS GWs, MMEs and SGSNs that are registered 
for corresponding MBMS bearer service and to E-UTRAN/UTRAN that have accept to receive IP multicast 
distribution. 

8.5.1 MBMS Session Stop Procedure for GERAN and UTRAN for GPRS 

The overall MBMS Session Stop procedure is presented in the following figure: 
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Figure 10: MBMS Session Stop procedure for GERAN and UTRAN for GPRS 

1. The BM-SC Session and Transmission function sends a Session Stop Request message to the BM-SC Proxy and 
Transport function, which forwards it to all GGSNs listed in the "list of downstream nodes" parameter of the 
affected MBMS Bearer Context to indicate that the MBMS session is terminated and the bearer plane resources 
can be released. The MBMS Bearer Context is uniquely identified by the TMGI or the combination of TMGI 
and Flow Identifier. The BM-SC Proxy and Transport function sets the state attribute of its MBMS Bearer 
Context to 'Standby'. The GGSN sends a Session Stop Response message to the BM-SC Proxy and Transport 
function, which forwards it to the BM-SC Session and Transmission function. The BM-SC Proxy and Transport 
function copies Session Stop Requests to the BM-SC Membership function for charging purposes. 

2. The GGSN sends an MBMS Session Stop Request message to all SGSNs that have a bearer plane established 
with the GGSN, releases the corresponding bearer plane resources towards these SGSNs and sets the state 
attribute of its MBMS Bearer Context to 'Standby'. The GGSN releases the MBMS Bearer Context in case of a 
broadcast MBMS bearer service. 

3. The SGSN releases the TEID and bearer plane resources on which it was receiving MBMS data from the GGSN 
for the affected MBMS bearer service and sends an MBMS Session Stop Request message to all BSCs/RNCs 
that have a bearer plane established with the SGSN and sets the state attribute of its MBMS Bearer Context to 
'Standby'. The SGSN releases the MBMS Bearer Context in case of a broadcast MBMS bearer service. 

3a If the RNC/BSC is using IP multicast distribution it shall disable reception from the IP backbone of the 
particular MBMS bearer service according to RFC 3376 [19], RFC 3810 [20] and RFC 4604 [22]. 
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4. The RNC releases the affected radio and lu resources; the BSC releases the affected radio resources. The 

BSC/RNC sets the state attribute of its MBMS Bearer Context to 'Standby'. The BSC/RNC releases the MBMS 
Service Context in case of a broadcast MBMS bearer service. A BSC in Gb mode shall send an 
acknowledgement to the SGSN even if there is no active MBMS context in the BSC. 

8.5.2 MBMS Session Stop Procedure for E-UTRAN and UTRAN for EPS 

The overall MBMS Session Stop procedure is presented in the following figure: 
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Figure 10b: MBMS Session Stop procedure for E-UTRAN and UTRAN for EPS 

1. The BM-SC sends a Session Stop Request message to the MBMS GW listed in the "list of down stream nodes" 
parameter of affected MBMS Bearer Context to indicate the end of session and the bearer plane resources can be 
released. The MBMS Bearer Context is uniquely identified by the TMGI or the combination of TMGI and Flow 
Identifier. The BM-SC sets the state attribute of its MBMS Bearer Context to 'Standby'. The MBMS GW 
responses with Session Stop Response and release its information regarding the session. 

2. The MBMS GW forwards Session Stop Request message to the MME/SGSN which previously received the 
Session Start Request message, release the corresponding bearer plane resources to E-UTRAN/UTRAN and sets 
the state attribute of its MBMS Bearer Context to 'Standby'. The MBMS GW releases the MBMS Bearer Context 
in case of a broadcast MBMS bearer service. 

3. MME/SGSN forwards Session Stop Request message to the E-UTRAN/UTRAN which previously received the 
Session Start Request message and sets the state attribute of its MBMS bearer Context to 'Standby'. Each 
E-UTRAN/UTRAN responds with Session Stop Response message to the MME/SGSN. The MME/SGSN 
releases the MBMS Bearer Context in case of a broadcast MBMS bearer service. 

3a If the E-UTRAN/UTRAN is using IP multicast distribution it shall disable reception from the IP backbone of the 
particular MBMS bearer service according to RFC 3376 [19], RFC 3810 [20] and RFC 4604 [22]. 

4. The E-UTRAN/UTRAN releases the affected resources and removes the MBMS Bearer Context (in E-UTRAN) 
or sets the state attribute of its MBMS Bearer Context to 'Standby' (in UTRAN). 

8.6 MBMS De-Registration Procedure 
8.6.0 Common MBMS De-Registration procedure 

The MBMS De-Registration is the procedure by which a downstream node informs an upstream node that it does not 
need to receive signalling, session attributes and data for a particular MBMS bearer service anymore and therefore 
would like to be removed from the corresponding distribution tree. 
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The MBMS De-registration procedure is initiated: 

- By the SGSN or GGSN when the last MBMS UE Context for a particular MBMS bearer service is deleted from 
the node and the "list of downstream nodes" parameter in the corresponding MBMS Bearer Context is empty; 

By the SGSN or GGSN when the last node registered in the "list of downstream nodes" de-registers from an 
MBMS bearer service for which there is no corresponding MBMS UE Context; or 

- By the DRNC that registered at an SGSN when it deletes the associated MBMS Service Context. 
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Figure 11: MBMS De-Registration Procedure 

When the DRNC that is registered at an SGSN no longer hosts any UE interested in that MBMS bearer service, 
the DRNC requests the de-registration from the MBMS bearer service to its parent SGSN. As an implementation 
option, the DRNC may decide not to de-register from the MBMS bearer service immediately when these 
conditions are met, e.g. in order to avoid unnecessary signalling in the case where the RNC would again need the 
same MBMS bearer service shortly after. 

The SGSN removes the identifier of the RNC from the "list of downstream nodes" parameter of the affected 
MBMS Bearer Context and confirms the operation by sending an MBMS De-Registration Response message to 
the RNC. If an lu bearer plane had been established between the DRNC and the SGSN for this MBMS bearer 
service, the lu bearer plane is released. If the RNC is using IP multicast distribution it shall disable reception 
fromthelPbackboneof the particular MBMS bearer service according to RFC 3376 [19], RFC 3810 [20] and 
RFC 4604 [22]. 

When the "list of downstream nodes" of a particular MBMS Bearer Context in the SGSN becomes empty and 
the SGSN has no MBMS UE Contexts linked to that MBMS Bearer Context, the SGSN sends an MBMS De- 
Registration Request (IP multicast address, APN) message to its upstream GGSN associated with the MBMS 
Bearer Context. 

The GGSN removes the identifier of the SGSN from the "list of downstream nodes" parameter of the affected 
MBMS Bearer Context and confirms the operation by sending an MBMS De-Registration Response message to 
the SGSN. If a bearer plane had been established between the SGSN and the GGSN for this MBMS bearer 
service, the bearer plane is released. 

When the "list of downstream nodes" of a particular MBMS Bearer Context in the GGSN becomes empty and 
the GGSN has no MBMS UE Contexts linked to that MBMS Bearer Context, the GGSN sends a De-Registration 
Request (IP multicast address, APN) message to the BM-SC. Proxy and Transport function If a bearer plane had 
been established over Gi for this MBMS bearer service, the bearer plane is released. 
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The BM-SC removes the identifier of the GGSN fi-om the "list of downstream nodes" parameter of the affected 
MBMS Bearer Context and confirms the operation by sending a De-Registration Response message to the 
GGSN. 

8.6.1 BM-SC initiated MBMS De-Registration Procedure 

This MBMS De-Registration Procedure is initiated by BM-SC when the specific MBMS bearer service is terminated. 
This procedure tears down the distribution tree for the deHvery of session attributes and MBMS data. This procedure 
resuhs in releasing of all MBMS Bearer Contexts and associated MBMS UE Contexts in the nodes along the 
distribution tree. 
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Figure 12: BM-SC initiated IVIBIVIS De-Registration Procedure 

1. The BM-SC sends a De-Registration Request message to all GGSNs contained in the "list of downstream nodes" 
parameter of the corresponding MBMS Bearer Context to indicate the session is terminated and any related 
MBMS bearer resources shall be released. 

The GGSN returns a De-Registration Response message to the BM-SC. The BM-SC releases all MBMS UE 
Contexts and the corresponding MBMS Bearer context. 

2. The GGSN sends an MBMS De-Registration Request message to all SGSNs contained in the "Hst of 
downstream nodes" parameter, of the corresponding MBMS Bearer Context. The SGSN returns an MBMS De- 
registration Response message to the GGSN and releases all bearer resources if the state attribute of the MBMS 
Bearer Context is 'Active'. The GGSN releases all MBMS UE Contexts and the affected MBMS Bearer Context. 
If a bearer plane had been established over Gi for this MBMS bearer service, the bearer plane is released. 

3. The SGSN sends an MBMS De-Registration Request message to all BSCs/RNCs connected with this SGSN. 
The BSC/RNC returns an MBMS De-Registration Response message to the SGSN, and releases all bearer 
resources if the state attribute of the MBMS Service Context is 'Active'. If the BSC/RNC is using IP multicast 
distribution it shall disable reception from the IP backbone of the particular MBMS bearer service according to 
RFC 3376 [19], RFC 3810 [20] and RFC 4604 [22]. The SGSN releases all MBMS UE Contexts and the 
affected MBMS Bearer Context. If a bearer plane had been established between the SGSN and the GGSN for 
this MBMS bearer service, the bearer plane is released. 

4. The BSC/RNC releases the affected radio resources, all MBMS UE Contexts and the MBMS Service Context. 
The detailed procedures are specified in TS 25.346 [10] and TS 43.246 [11]. RAN may notify the UEs that the 



£75/ 



3GPP TS 23.246 version 1 0.0.0 Release 1 47 ETSI TS 1 23 246 V1 0.0.0 (201 1 -03) 

MBMS Bearer service has being terminated, so that the UE can locally deactivate its MBMS UE context, 
detailed procedures are specified in TS 25.346 [10] and TS 43.246 [11]. 

8.7 MBMS Multicast Service Deactivation 

The multicast service deactivation is a signalling procedure between the UE and the network. The procedure removes 
the MBMS UE Context from the UE, RAN, SGSN and GGSN for a particular MBMS multicast service. The multicast 
service deactivation can be initiated by: 

- The UE; 

- The GGSN; 

- The BM-SC; or 

- The SGSN 

All these cases are contained in the procedure illustrated in figure 13. The UE initiated Multicast Service Deactivation 
starts with step 1), the BM-SC initiated Multicast Service Deactivation starts with step 3), the GGSN initiated Multicast 
Service Deactivation starts with step 4), the SGSN initiated Multicast Service Deactivation starts with step 5) or 9), and 
the MBMS UE de-linking is performed at step 7). 

At GPRS detach, all MBMS UE contexts of the UE are implicitly deactivated in the UE, SGSN and GGSN, i.e. the 
SGSN performs the deactivation procedure starting with step 7). 

If the PDP context linked to the MBMS UE context by the Unked NS API is deactivated by the UE or SGSN or GGSN, 
then the SGSN shall perform the MBMS deactivation procedure starting with step 7). The UE will remove all MBMS 
UE Contexts locally after the Linked PDP Context was deactivated. 
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Figure 13: MBMS Multicast Service Deactivation 

1 . The UE sends an IGMP (IPv4) or MLD (IPv6) Leave message (here, the Leave message means Leave Group 
message in RFC 2236 for IGMP (IPv4) and Multicast Listener Done in RFC2710 for MLD (IPv6)) over the 
default PDP context to leave a particular multicast service identified by an IP multicast address. 

2. The GGSN sends a Leave Indication (IP multicast address, APN,IMSI) to the BM-SC Proxy and Transport 
function, which forwards it to the BM-SC Membership function, indicating that the UE is requesting to leave the 
multicast service identified by the IP multicast address. The exact nature of the signalling between GGSN and 
BM-SC is specified in TS 29.061 [4]. 

3. Upon reception of the Leave Indication, the BM-SC Membership function verifies that the IP multicast address 
corresponds to a valid MBMS bearer service and sends a UE Removal Request (IP multicast address, APN, 
IMSI) to the GGSN that originated the Leave Indication. The APN shall be the same that was provided during 
service activation (see "MBMS Multicast Service Activation"). The exact nature of the signalling between 
GGSN and BM-SC is specified in TS 29.061 [4]. The BM-SC Membership function may also initiate the 
deactivation of an MBMS UE Context for service-specific reasons (e.g. the service is terminated but the UE has 
not yet left the multicast group) by directly sending a UE Removal Request message to the GGSN. 

4. Upon reception of the UE Removal Request or for other reasons (e.g. Error cases), the GGSN sends an MBMS 
UE Context Deactivation Request (IP multicast address, APN, IMSI) to the SGSN. The IP multicast address, 
APN and IMSI together identify the MBMS UE Context to be deleted by the SGSN. The APN is the one 
received in step 3. The SGSN acknowledges reception of the MBMS UE Context Deactivation Request by 
sending an MBMS UE Context Deactivation Response to the GGSN. 
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5. Upon reception of the MBMS UE Context Deactivation Request or for other reasons (e.g. due to a change in the 
roaming restrictions for the user) the SGSN sends a Deactivate MBMS Context Request (TI) to the UE. The TI 
identifies the MBMS UE Context to be deleted by the UE. 

6. The UE deletes the MBMS UE Context and sends a Deactivate MBMS Context Accept (TI) to the SGSN. 

7. If the UE is PMM-CONNECTED and has been already linked towards the RAN, t he SGSN sends a MBMS UE 
De-Linking Request to the RNC (IP multicast address, APN, TMGI). RAN deletes the MBMS UE Context and 
sends a MBMS UE De-Linking Response (TMGI ) to the SGSN. 

8. If dedicated radio resources are currently assigned to the UE for the reception of the MBMS data, the RAN 
releases these radio resources. If shared radio resources are currently assigned for the distribution of the MBMS 
data, the RAN may decide to move the remaining UEs to dedicated resources. The detailed procedures and 
conditions are specified in TS 25.346 [10] and TS 43.246 [11]. 

9. Upon reception of the Deactivate MBMS Context Accept or for other reasons (e.g. due to expiry of the long 
timer that is started upon a periodic routeing area update not being received) the SGSN sends a Delete MBMS 
Context Request (MBMS_NSAPI) to the GGSN that holds the MBMS UE Context. This GGSN may be 
different from the GGSN that receives IGMP Leave request in step 1. 

10. The GGSN deletes the MBMS UE Context and sends a Deactivation Indication to the BM-SC to confirm the 
successful deactivation of the MBMS UE Context. The BM-SC, after receiving the Deactivation Indication, 
deletes the MBMS UE Context and sends a confirmation to the GGSN. The exact nature of the signalling 
between GGSN and BM-SC is specified in TS 29.061 [4]. 

1 1 . If the GGSN does not have any more users interested in this MBMS bearer service and the "list of downstream 
nodes" in the corresponding MBMS Bearer Context is empty, the GGSN sends a MBMS De-Registration 
Request to the BM-SC Proxy and Transport function. The BM-SC Proxy and Transport function responds with a 
MBMS De-Registration Response and removes the identifier of the GGSN from the "list of downstream nodes" 
parameter in its MBMS Bearer Context. See clause "MBMS De-Registration Procedure". 

12. The GGSN confirms the deactivation of the MBMS UE Context to the SGSN by sending a Delete MBMS 
Context Response to the SGSN, which then deletes the MBMS UE Context. 

13. If the SGSN does not have any more users interested in this MBMS bearer service and the "list of downstream 
nodes" in the corresponding MBMS Bearer Context is empty, the SGSN sends an MBMS De-Registration 
Request to the GGSN. The GGSN responds with an MBMS De-Registration Response and removes the 
identifier of the SGSN from the "list of downstream nodes" parameter in its MBMS Bearer Context. See clause 
"MBMS De-Registration Procedure". 

8.8 MBMS Session Update procedure 

8.8.1 General 

The MBMS Session Update procedure may be invoked by BM-SC or by SGSN. The BM-SC uses the procedure to 
update the service area for an ongoing MBMS Broadcast service session. The SGSN can also use the procedure to 
update the list of RAs where MBMS multicast users are located for an ongoing MBMS Multicast service session. 

8.8.2 SGSN initiated Session Update for GERAN and UTRAN for MBMS 
Multicast service 

If the SGSN has provided a list of RAs in the MBMS Session Start Request message (even if the list was empty) and 
RAs are added or removed from the list, the SGSN shall use the MBMS Session Update procedure to inform the RNCs 
that the list has changed. The SGSN sends the Session Update message only to the RNCs that are affected by the list 
change. The procedure is used only during the MBMS Multicast service session and when SGSN has already sent a 
MBMS Session Start Request message to the RNC. 

If the SGSN has provided a list of RAs in the MBMS Session Start Request message (even if the list was empty) the 
SGSN shall send the Session Update to a RNC when: 

- the first UE which have activated the service enters in a RA that is not in the list; 
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the last UE which have activated the service leaves from a RA that was in the list. 
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Figure 13a. Session Update procedure 

1) The SGSN sends MBMS Session Update Request message to a RNC. 

2) The RNC acknowledges the MBMS Session Update Request with the MBMS Session Update Response 

message. 

8.8.3 BM-SC initiated Session Update for GERAN and UTRAN for MBMS 
Broadcast service 

The BM-SC initiates the MBMS Session Update procedure when the service area for an ongoing MBMS Broadcast 
service session shall be modified. 

The attributes that can be modified by the Session Update Request are the MBMS Service Area, and the list of 
downstream nodes for GGSN (Broadcast only). A node receiving the Session Update Request determines how the 
attributes have changed by comparing the attributes in the message with corresponding attributes in its stored MBMS 
Bearer Context. 

A Session Update received in one node, results in a Session Update being sent to downstream nodes, to inform of the 
changed MBMS Service Area. If a Session Update with the List of SGSN parameter included is received in the GGSN, 
it does also result in a Session Start being sent to new downstream nodes, and in a Session Stop being sent to 
downstream nodes that have been removed from the list. 

The overall Session Update procedure is presented in figure 13b. 
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Figure 13b: Session Update procedure for GERAN and UTRAN 

1 . The BM-SC Session and Transmission function sends a Session Update Request (TMGI, Flow Identifier 

(Broadcast only), QoS, MBMS Service Area, Session identifier, estimated session duration, broadcast/multicast, 
list of downstream nodes for GGSN, time to MBMS data transfer) to the BM-SC Proxy and Transport function, 
which then forwards it to the GGSNs listed in the "list of downstream nodes" parameter of the corresponding 
MBMS Bearer Context. The TMGI and Session identifier identifies the ongoing session. The QoS, 
broadcast/multicast attributes and the 2G/3G indicator shall be identical as in the preceding Session Start 
message. The MBMS Service Area and the List of downstream nodes for GGSN define the new service area. 
The time to MBMS data transfer shall be set to and the estimated session duration shall be set to a value 
corresponding to the remaining part of the session. 
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The GGSN stores the new session attributes and the list of downstream nodes in the MBMS Bearer Context and 
sends a Session Update Response message to the BM-SC Proxy and Transport function which forwards it to the 
BM-SC Session and Transmission function. The BM-SC Proxy and Transport function copies the Session 
Update Request to the BM-SC Membership function for charging purposes. 

2. The GGSN compares the new Hst of downstream nodes with the Hst of downstream nodes it has stored in the 
MBMS Bearer Context. It sends an MBMS Session Start Request message to any added SGSN, an MBMS 
Session Stop Request to any removed SGSN, and an MBMS Session Update Request to the remaining SGSNs in 
the new Hst. 

3. The SGSN receiving an MBMS Session Update Request message, sends an MBMS Session Update Request 
message including the session attributes (TMGI, QoS, MBMS service Area, Session identifier, estimated session 
duration, broadcast/multicast, time to MBMS data transfer, list of RAs, etc.) to each BSC and/or each RNC that 
is connected to this SGSN. 

4. The BSCs/RNCs establish or release the necessary radio resources for the transfer of MBMS data to the 
interested UEs. 

8.8.4 BM-SC initiated Session Update for EPS witii E-UTRAN and 
UTRAN 

The BM-SC initiates the MBMS Session Update procedure when the service attributes (e.g. Service Area) for an 
ongoing MBMS Broadcast service session shall be modified, e.g. the Session Update procedure for EPS is initiated by 
BM-SC to notify eNBs to join or leave the service area. 

The attributes that can be modified by the Session Update Request are the MBMS service area. Access indicator, and 
the List of MBMS control plane nodes. A node receiving the Session Update Request determines how the attributes 
have changed by comparing the attributes in the message with corresponding attributes in its stored MBMS Bearer 
Context. 

A Session Update received in one node, results in a Session Update being sent to downstream nodes, to inform of the 
changed MBMS service attributes. If a Session Update with the List of MME and SGSN parameter included is received 
in the MBMS GW, it does also result in a Session Start being sent to new downstream nodes, and in a Session Stop 
being sent to downstream nodes that have been removed from the list. 

The overall Session Update procedure is presented in figure 13c. 
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Figure 13c: Session Update procedure for EPS with E-UTRAN and UTRAN 
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1. The BM-SC sends a Session Update Request (TMGI, Flow Identifier, QoS, MBMS Service Area, Session 
identifier, estimated session duration, the Hst of MBMS control plane nodes(MMEs, SGSNs) for MBMS GW, 
Access Indicator . . .) to MBMS GW. The TMGI and Session identifier identifies the ongoing session. The QoS 
shall be identical as in the preceding Session Start message. The MBMS Service Area and the list of MBMS 
control plane nodes(MMEs, SGSNs) for MBMS GW define the new service area. The estimated session duration 
shall be set to a value corresponding to the remaining part of the session. If radio access of MBMS service is 
updated the Access indicator shall be included and indicate in which radio access types the MBMS service 
should be broadcasted, i.e. UTRAN, or E-UTRAN, or both. The Access indicator may be included in charging 
information generated by the MBMS-GW. 

2. The MBMS GW stores the new session attributes in the MBMS Bearer Context and sends a Session Update 
Response message to the BM-SC. 

3. The MBMS GW filters the new list of MBMS control plane nodes using the Access indicator to ignore entries 
not consistent with the Access indicator, and compares remaining entries in the new list of MBMS control plane 
nodes with the list of MBMS control plane nodes it has stored in the MBMS Bearer Context. It sends an MBMS 
Session Start Request message to any added MME/SGSN, an MBMS Session Stop Request to any removed 
MME/SGSN, and an MBMS Session Update Request (TMGI, Flow Identifier, QoS, MBMS Service Area, 
Session identifier, estimated session duration, transport network IP Multicast Address, IP address of the muticast 
source, C-TEID, ...) to the remaining MME/SGSNs in the new list. The handlings of the MBMS Session 
Start/Stop Request message are described in clauses 8.3.2 and 8.5.2. 

4. The MME/SGSN receiving an MBMS Session Update Request message, sends an MBMS Session Update 
Request message including the session attributes (TMGI, QoS, MBMS service Area, Session identifier, 
estimated session duration, broadcast(for UTRAN only), transport network IP Multicast Address, IP address of 
the muticast source, C-TEID, ...) to each eNodeB/RNC that is connected to the MME/SGSN. 

For UTRAN, if one or more of the downstream nodes newly added to the MBMS Service Area accepts the 
Session Update and the proposed IP Multicast and Source address for backbone distribution and the proposed 
C-TEID, the SGSN includes an indication that IP Multicast distribution is accepted in the MBMS Session 
Update Response message to MBMS GW. If one or more of the downstream nodes newly added to the MBMS 
Service Area does not accept the proposed IP Multicast and Source address for backbone distribution or the 
proposed C-TEID, the SGSN falls back to normal point-to-point MBMS bearer establishment for these nodes 
and responds with an MBMS Session Update Response message providing the TEID for bearer plane that the 
MBMS GW shall use for forwarding the MBMS data. Otherwise if all nodes accept multicast, the SGSN returns 
the C-TEID and the IP Multicast distribution address in the Session Update Response message. 

5. If the E-UTRAN/UTRAN has no the MBMS bearer context with the TMGI indicated in the MBMS Session 
Update Request message, the E-UTRAN/UTRAN creates an MBMS bearer context and sets its state attribute to 
Active' (in UTRAN only). Otherwise the E-UTRAN/UTRAN compare the new service area with the one it has 
stored in the MBMS Bearer Context and make the corresponding update. Then the E-UTRAN/UTRAN responds 
the MME/SGSN to confirm the reception of the Session Update Request message. 

For UTRAN, if an RNC newly added to the MBMS Service Area accepts the Session Update and the proposed 
IP Multicast and Source address for backbone distribution and the proposed C-TEID the RNC sends an MBMS 
Session Update Response message to SGSN including an indication that IP Multicast distribution is accepted. If 
an RNC newly added to the MBMS Service Area does not accept the proposed IP Multicast and Source address 
for backbone distribution (or the proposed C-TEID), the RNC falls back to normal point-to-point MBMS bearer 
establishment. 

6. The MME/SGSN updates the session attributes in its MBMS Bearer Context and responds to the MBMS GW. 

Editor's Note; It is FES if SGSN or MME need wait response from any, one or all UTRAN/E-UTRAN nodes and if 
SGSN and MME behave same way. 

7. The E-UTRAN/UTRAN establishes/releases the radio resources for the transfer of MBMS data to the interested 
UEs. 

8. The eNodeBs/RNCs send IP multicast Join or Leave message to the received user plane IP multicast address 
allocated by the MBMS GW. 
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8.9 MBMS UE Context Synchronisation Procedure 

The Routing Area Update procedure transfers the MBMS UE Context status between UE and SGSN. This MBMS UE 
Context status identifies MBMS UE contexts, which are lost or deactivated only on one side. All MBMS UE Contexts, 
which are active on one side only shall be deactivated locally. If the UE wishes to re-activate the related MBMS bearer 
service, it shall join the MBMS bearer service again. See clause 8.2 "MBMS Multicast Service Activation". 



UE 



SGSN 



1. Routeing Area Update Request 

N 

2. Routeing Area Update Accept 



Figure 13d. MBMS UE Context Synchronisation procedure 

1) The UE sends Routeing Area Update Request to the SGSN. It includes the MBMS UE Context status, which 
indicates the UE's active MBMS UE Contexts. 

2) The SGSN sends Routeing Area Update Accept to the UE. It includes the MBMS UE Context status, which 
indicates the UE's MBMS UE Contexts that are stored in the SGSN. 

8.9a IVIBIVIS feature support indication 

An SGSN that supports MBMS shall indicate MBMS feature support to the UE during Routing Area Update procedure 
in the Routing Area Update Accept message and during GPRS attach procedure in the Attach Accept message. The UE 
then knows it can use already activated MBMS bearers, or activate new MBMS bearers according to clause 8.2 "MBMS 
Multicast Service Activation". 

An SGSN that does not support MBMS will not indicate MBMS feature support to the UE. This indicates to the UE that 
MBMS bearers are no longer supported, which may allow the UE to use point-to-point bearers for MBMS data transfer. 
In this case, the UE shall deactivate all active MBMS UE Contexts locally. 

8.10 Inter SGSN Routeing Area Update 

This procedure describes the handling of MBMS bearer services when an MBMS UE performs a Routeing Area Update 
and the serving SGSN changes. It is based on the Inter SGSN Routeing Area Update procedure specified in 
TS 23.060 [15]. The procedure is performed regardless whether MBMS sessions are ongoing or not. The handling of 
any PDF contexts established by the UE is not changed compared to the procedure without MBMS. The procedure 
described below does not show all details of the Routeing Area update procedure. Only for the MBMS specific 
additions the steps are described. 
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Figure 14: Inter SGSN Routeing Area Update 

2) An SGSN supporting MBMS indicates its MBMS support in the SGSN Context Request message. If the SGSN 
indicates that it supports MBMS, the old SGSN includes the transfer of the MBMS UE Context(s) in the SGSN 
Context Response message. 

7) For the MBMS UE context(s) received in step 2) the new SGSN sends Update MBMS UE Context Request 
(Serving network identity, MS Time Zone, CGI/SAI, RAT Type, Additional MBMS Trace Info) to the GGSNs 
concerned. The GGSNs update their MBMS UE Context fields and return Update MBMS UE Context Response. 

8) The GGSN sends Update MBMS UE Context Request (RAI) to the BM-SC. The inclusion of CGI/SAI shall be 
according rules detailed in clause 15.1.1a in TS 23.060 [15]. The BM-SC updates its MBMS UE Context fields 
and return Update MBMS UE Context Response. 

9) If the GGSN receives new or updated Additional MBMS Trace Info from the new SGSN, the GGSN sends an 
Activate Trace (Additional MBMS Trace Info) message to the BM-SC. 
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14) In case the new SGSN indicated no MBMS support in step 2) the old SGSN deactivates all MBMS UE 
context(s) of the UE in SGSN, GGSN and BM-SC by initiating deactivation procedure(s) as described in clause 
"8.7 MBMS Multicast Service Deactivation". 

15) If the old SGSN does not have any more MBMS UE Contexts for the MBMS bearer service(s) and the "list of 
downstream nodes" in the corresponding MBMS Bearer Context is empty, the SGSN initiates the MBMS De- 
Registration Procedure. See clause "8.6 MBMS De-Registration Procedure". 

16) In case the new SGSN indicated MBMS support in step 2), the new SGSN verifies for each MBMS UE Context 
received whether it has a corresponding MBMS Bearer Context. For each MBMS Bearer Context that the SGSN 
does not already have, the SGSN creates an MBMS Bearer Context (in "Standby" state) and initiates the MBMS 
Registration Procedure towards the GGSN. See clause "8.4 MBMS Registration Procedure". 

17) An SGSN without MBMS support does not indicate MBMS feature support in the Routing Area Update Accept 
message. On the other hand if the SGSN supports MBMS, the Routing Area Update Accept indicates to the UE 
that the network supports MBMS. 

8.10a Inter-system Intra-SGSN change 

For an MBMS UE transitioning between UTRAN and A/Gb mode GERAN, the procedures are the same as the lu mode 
to A/Gb mode Intra SGSN Change and A/Gb mode to lu mode Intra SGSN Change procedures specified in 
TS 23.060 [15]. 

Furthermore, the same considerations on Radio Access Technology changes apply as specified in the impacts of 
applying flow based charging specified in TS 23.060 [15], i.e. the SGSN shall send an Update MBMS UE Context 
Request to the GGSN. Subsequently the GGSN shall send an Update MBMS UE Context Request to the BM-SC as 
described in the Inter SGSN Routeing Area Update procedure in clause 8.10. 

8.1 1 Inter SGSN Serving RNS Relocation Procedure 

This procedure is performed when the SGSN changes due to SRNS relocation. It bases on the SRNS Relocation 
procedure specified in TS 23.060 [15]. The procedure is performed regardless whether MBMS sessions are ongoing or 
not. The handling of any PDP contexts established by the UE is not changed compared to the procedure without 
MBMS. The procedure described below does not show all details of the SRNS relocation procedure. Only for the 
MBMS specific additions the steps are described. 
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Figure 15: SRNS Relocation Procedure 

3) The old SGSN transfers the MBMS UE Context(s). in the Forward Relocation Request message to the new 
SGSN 

5) An MBMS supporting SGSN indicates its MBMS support in the Forward Relocation Response message. 

14) In case the new SGSN supports MBMS it verifies for each MBMS UE Context received whether it has a 

corresponding MBMS Bearer Context. For each MBMS Bearer Context not yet existing in the SGSN the SGSN 
creates an MBMS Bearer Context (in "Standby" state) and initiates the MBMS Registration Procedure. See 
clause "MBMS Registration Procedure". 
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16) In case the new SGSN indicated no MBMS support in step 3) the old SGSN deactivates all MBMS UE contexts 
of the UE in SGSN, GGSN and BMSC by initiating deactivation procedure(s) as described in clause "8.7 MBMS 
Multicast Service Deactivation". 

17) If the old SGSN does not have any more MBMS UE Contexts for this MBMS bearer service and the "Ust of 
downstream nodes" in the corresponding MBMS Bearer Context is empty, the SGSN initiates the MBMS De- 
Registration Procedure. See clause "MBMS De-Registration Procedure". 

18) If the new SGSN supports the MBMS and for the MBMS UE context(s) received in step 5) the new SGSN sends 
Update MBMS UE Context Request (Serving network identity, MS Time Zone, CGI/SAI, RAT Type, 
Additional MBMS Trace Info) to the GGSNs concerned. The GGSNs update their MBMS UE Context fields and 
return Update MBMS UE Context Response. The GGSN sends updated Serving network identity to the BM-SC. 
The inclusion of CGI/SAI shall be according rules detailed in sub-clause 15.1.1a in TS 23.060 [15]. 

19)If the GGSN receives new or updated Additional MBMS Trace Info from the new SGSN, the GGSN sends an 
Activate Trace (Additional MBMS Trace Info) message to the BM-SC. 

20) An SGSN without MBMS support does not indicate MBMS feature support in the Routing Area Update Accept 
message. On the other hand if the SGSN supports MBMS, the Routing Area Update Accept indicates to the UE 
that the network supports MBMS. 

8.12 MBMS Broadcast Service Activation 

MBMS Broadcast service activation is the procedure by which a UE locally activates a broadcast MBMS bearer 
service: 

The MBMS broadcast service activation procedure does not register the user in the network. There is no MBMS 
bearer service specific signalling exchanged between the UE and the Network. 

The broadcast service activation procedure does not establish MBMS UE contexts in UE, SGSN and GGSN. 

8.13 MBMS Broadcast service de-activation 

The MBMS Broadcast service de-activation by the UE is local to the UE, i.e. without interaction with the Network. 

8.14 Void 

8.15 MBMS UE Linking/De-linking mechanism 

MBMS UE Linking is the process by which UE MBMS context(s) is (are) provided to an lu-mode RAN. 
MBMS UE linking procedure is performed when the UE is PMM-CONNECTED at least in the following cases. 

- When a UE which has a MBMS UE context is moved to the PMM CONNECTED state and a PS RAB is 
established. This may happen at any point in time e.g. before, during and between Sessions. 

- When a UE joins the MBMS bearer service and is in the PMM CONNECTED state due to an existing PS RAB. 
This may happen at any point in time e.g. before, during and between Sessions. 

When a UE is moved to the PMM CONNECTED state via the MBMS Service Request procedure. This may 
happen at any point in time during a MBMS session. 

The UE linking is performed to link a specific UE to an MBMS service. It provides the SRNC/Iu-mode BSC with a list 
of MBMS service identifiers (including TMGI) for MBMS bearer services activated by the UE. If no MBMS service 
context exists for this particular MBMS bearer service then the SRNC/Iu-mode BSC creates an MBMS service context 
after this procedure. 

NOTE: the MBMS Bearer Context is referred to as the MBMS Service Context in 3GPP RAN specifications 

MBMS UE De-Linking denotes the process where a MBMS UE context is removed from the RAN. 
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MBMS UE De-Linking procedure is performed if the UE is PMM-CONNECTED and has been akeady linked towards 
the RAN at least when it initiates MBMS Multicast Service Deactivation procedure. This may happen at any point in 
time during the whole MBMS service availability i.e. before, during and between MBMS sessions. 

The UE De-Linking is performed to unlink a specific UE from a MBMS service. The entry for this UE is removed from 
the concerned MBMS service context(s) in the SRNC. 

8.16 MBMS Service Request Procedure 

For MBMS, when UTRAN wants to count the number of users that are interested in a specific MBMS service which are 
present in a cell, it will request a percentage of the interested UEs to transit to PMM-CONNECTED state. The MBMS 
Service Request procedure is used by a UE in the PMM-IDLE state to move to the PMM-CONNECTED state. The 
MBMS Service Request procedure is also used by a UE in PMM IDLE or PMM-CONNECTED state to request to be 
maintained in PMM-CONNECTED state for the purpose of receiving data over an MBMS point-to-point radio bearer. 
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Figure 17: MBMS Service Request procedure 

1) An RRC connection is established if it doesn't akeady exist. 

2) The UE sends a Service Request message to the SGSN if MBMS PTP reception shall be used or if otherwise 
required to do so by the RAN when MBMS reception shall be started. The Service Type shall indicate MBMS 
multicast service reception or MBMS broadcast service reception. The SGSN shall not release the lu signalling 
connection until requested by the RAN. 

3) The SGSN may perform the security functions. 

4) The SGSN provides the RAN with the IMSI of the UE. 

5) The SGSN provides the RAN with the MBMS UE context(s) (IP multicast address/ APN, TMGI, 
MBMS_NSAPI) via MBMS UE Linking procedure, if the SGSN has active MBMS UE context(s) for the UE. 
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NOTE: Step 6 is independent of steps 4 to 5 and can occur before or simultaneously with any of these steps. 

6) The RNC establishes the necessary radio resources for the transfer of MBMS data to the interested UEs. 

7) When PTP transmission of a MBMS multicast or MBMS broadcast service is active for a UE then the RNC shall 
supervise the lu signalling connection. When the RAN determines that it does not need to keep the UE in RRC- 
CONNECTED state anymore, it shall trigger a normal lu release towards SGSN. 

8.1 7 Notification in case of parallel services 

8.17.1 Notification of incoming CS domain call during an ongoing MBMS 
session 

For the RRC connected mobiles in UTRAN, the RNS will have received the IMSI from the core network and hence is 
able to perform paging coordination. The UEs in RRC idle state in UTRAN need to perform paging coordination while 
receiving the MBMS session's user data. 

In GERAN, this is achieved by the UE monitoring its paging channels while receiving the MBMS session's user data. If 
the mobile responses to the CS paging in GERAN, then the ongoing MBMS service is likely to be interrupted in the 
UE. 

8.1 7.2 Notification of additional MBMS session during an ongoing MBMS 
session 

For the RRC connected mobiles in UTRAN, the SGSN has sent the list of MBMS bearer services that the user has 
activated to the UTRAN. The RNS needs to notify an RRC connected UE. 

For the UEs in RRC idle state, the UTRAN performs MBMS notification for the UE. 

In GERAN, this is achieved by the UE monitoring its paging channel(s) where notification is sent while receiving the 
MBMS session's user data. 

If the mobile accepts the new MBMS session in GERAN, then the ongoing MBMS service is likely to be interrupted in 
the UE. 

8.1 7.3 Notification of Mobile Terminating PS data during an ongoing MBMS 
session 

For the RRC connected mobiles in UTRAN, the SGSN request the establishment of a RAB which will be used to 
deliver the MT user data. 

For the UEs in RRC idle state, the UTRAN performs paging notification for the UE. 

In GERAN, this is achieved by the UE monitoring its paging channels while receiving the MBMS session's user data. 

If the mobile responses to the PS paging in GERAN, then the ongoing MBMS service is likely to be interrupted in the 
UE. 

8.1 7.4 Notification of MBMS session during an ongoing CS or PS domain 
"connection" 

When the UE establishes the UTRAN RRC connection for a CS service, the UE shall send a flag indicating that it has 
activated at least one MBMS bearer service. The RNC requests the SGSN to send the list of MBMS bearer services that 
the user has activated to enable the RNC to notify the UE when MBMS session starts. 

When a UE moves to PMM-connected state, the SGSN sends the list of MBMS bearer services that the user has 
activated to the RNC. The RNC notifies the UE when an MBMS session of the user's activated MBMS bearer services 
starts. 
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These procedures are not supported by GERAN in this version of the specification. 

9 Security 

Security of MBMS is found in TS 33.246 [5]. 

10 Charging requirement 
10.1 General 

The MBMS architecture shall support on-line and off-line charging. 

It shall be possible to collect charging information for the multicast mode. It shall also be possible to collect charging 
information for MBMS services in visited networks. 



MBMS shall collect charging information about the transmission of MBMS broadcast or multicast data that are 
provided by content or service providers (e.g. 3"* parties). This shall enable billing of broadcast and multicast content or 
service providers. 

To enable billing of broadcast and multicast content providers, data shall be collected at the BM-SC. 

NOTE: SGSN, GGSN and BM-SC generate charging data for the transmitted data, always under the assumption 
that the UEs are within the MBMS service area. If the MBMS service area is less than the PLMN, then 
there is the possibility that a UE will have moved outside the MBMS service area. Charging data will still 
be generated for that UE causing an inaccuracy in the data. This inaccuracy increases as the size of the 
MBMS service area is decreased. 



1 0.2 Bearer level charging for MBMS 



To provide bearer level charging for MBMS, mechanisms and functional elements described in TS 23.125 [12] are used 
for MBMS Bearer Contexts. 

For EPS, MBMS GW shall collect charging information about the transmission of MBMS broadcast for UTRAN and 
E-UTRAN. MBMS Bearer context in MBMS GW should include charging related information elements. 

Flow Based Charging (FBC) may be used to collect charging data records for MBMS Bearer Contexts e.g. for the 
purpose to charge the service provider, cf. TS 23.125 [12]. 

NOTE: Since multiple users share an MBMS bearer context FBC cannot be used for creating reports on a per user 

basis. 

1 0.3 Application level charging for MBMS 

For GPRS, in order to meet the MBMS charging requirements in TS 22.146 [2] and TS 22.246 [6], the following 
elements and functionalities are provided by the GPRS MBMS architecture: 

a) The MSISDN and IMSI are passed to the BM-SC. This provides the operator with the ability to associate GPRS 
location information (i.e. serving network idenity) with a user. 

b) In order to permit differential roaming tariffs, the serving network identity is provided to the BM-SC. 

c) Charging for MBMS services is based on application layer mechanisms, since it is only at the application layer 
that security is provided which can restrict content to authorised users or confirm delivery of content to users: 

The following general requirements apply to charging information generated by the BM-SC: 

Charging information generated for application layer charging events should include the above information 
provided by the GPRS network to facilitate differential roaming tariffs. 
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Charging information should include an indication of the point at which the user had access to the content 
(e.g. if and when decryption keys for encrypted content are sent to the UE.). 

For EPS, in order to meet the MBMS charging requirements in TS 22.146 [2], charging requirements for MBMS in EPS 
should be supported in broadcast mode and be same as that in broadcast mode for MBMS in GPRS network on 
application level. 

1 0.4 Generation of charging records in the VPLIVIN 

In this Release, charging for roaming scenario of MBMS in EPS will not be considered. 

For GPRS, in order to permit the settlement of inter-operator roaming charges , the SGSN needs to raise CDRs. The 
information that needs to be included on these CDRs is FES. 



1 1 Roaming Support for IVIBIVIS user services 

11.1 Scenarios description 

There are three specific scenarios to provide MBMS user services to roaming users. 

One uses a GGSN in the HPLMN, the other two are enabled by use of the Mz interface and are further described below: 

A visited PLMN may offer to roaming users MBMS user services from their home PLMN. For this case, the 
PDP connection, which will be used for the JOIN step, may always be from the UE to the V-GGSN due to 
operator policy or routing optimization, then the authorization is done in the BM-SC in visited PLMN with the 
authorization information retrieved from the BM-SC in home PLMN. Then the MBMS user traffic is provided 
by the BM-SC in home PLMN and proxied. An APN indicating a GGSN will be included in the authorisation 
information sent from home BM-SC to visited BM-SC. Whether GGSN of home or visited PLMN would be 
used is based on the operator policy, or agreement between PLMNs, for example, the visited BM-SC may 
modify the APN from the home BM-SC according to configuration of operator policy. 

Or, a visited PLMN may offer its own MBMS user services to roaming users when visited and home PLMN 
support the same classes of MBMS user services. For this case, the authorization is done in the BM-SC in visited 
PLMN with the authorization information retrieved from the BM-SC in home PLMN. Then the MBMS user 
traffic is provided by the BM-SC in visited PLMN. 

Editors' note: It is FES how to deal with the services in the BM-SC in visited network which are not the same 
service class as supported by the BM-SC in home network. 

The usage of any of the scenarios and the offered MBMS user services are subject to the roaming agreement between 
visited and home PLMN operators. 

11.2 Scenario signalling flow 
11.2.1 APN selection 

When a UE is authorized through the BM-SC in the visited PLMN (by proxying the authorization signalling), an APN 
may be selected and decided by the BM-SC in the home PLMN or the BM-SC in the visit PLMN depending on the 
operator policy or agreement between PLMNs. See step 4 of the figure 18. 
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Figure 18: MBMS route optimization for l-IPLMN provided MBMS services 

Figure 18 is an extension of MBMS multicast service activation procedure described in clause 8.2, the only revise is 
that an authorization step (step 4) is added according to clause 11.1. 

4. The BM-SC in visited PLMN finds the BM-SC in home PLMN which will serve the UE based on the multicast 
IP address, and identity of the user, and sends the authorization request to it. The BM-SC in home PLMN can 
respond with an APN, which indicates a GGSN in home PLMN which will serve the UE for the specific MBMS 
service. The BM-SC in the visit network may modify the APN based on the operator policy or agreement 
between PLMNs. 
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Annex A (Informative): 
Void 
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Annex B (Informative): 
Void 
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